From pcn-bounces@ietf.org Mon Oct 01 04:47:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcGvC-0006d2-Ug; Mon, 01 Oct 2007 04:46:34 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IcGvB-0006ct-Js for pcn-confirm+ok@megatron.ietf.org; Mon, 01 Oct 2007 04:46:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcGv7-0006c8-CW for pcn@ietf.org; Mon, 01 Oct 2007 04:46:29 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcGv6-0004IZ-MU for pcn@ietf.org; Mon, 01 Oct 2007 04:46:29 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Mon, 1 Oct 2007 10:46:23 +0200 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Oct 2007 10:46:22 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] PCN architecture, revised sub-section on probing X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 1 Oct 2007 10:46:22 +0200 Message-Id: <1B6169C658325341A3B8066E23919E1C0DE845@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN architecture, revised sub-section on probing thread-index: AcgCYqxeQQhUynnYTAGC7/bECjIArgBoXsRQ From: "Geib, Ruediger" To: X-OriginalArrivalTime: 01 Oct 2007 08:46:22.0776 (UTC) FILETIME=[8B42EB80:01C80407] X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Lars, thanks, I fully agree. I'm not looking for perfect solutions.=20 To me, the first generation of PCN specs should result in simple,=20 stable and secure in implementation and operation. The specs=20 should state their shortcomings and future standards may propose=20 more perfect solutions. If PCN domains can provide the desired service quality for admitted=20 flows without probing and ECMP awareness, I prefer not to work on=20 both for now.=20 Regards, Ruediger |-----Original Message----- |From: Lars Eggert [mailto:lars.eggert@nokia.com] |Sent: Saturday, September 29, 2007 8:31 AM |To: ext Steven Blake |Cc: pcn |Subject: Re: [PCN] PCN architecture, revised sub-section on probing | | |On 2007-9-28, at 21:15, ext Steven Blake wrote: |> If a probe packet for a PCN-managed flow is intended to follow the =20 |> same |> ECMP path as the flow, then the probe packet has to look exactly like |> flow packets in the header fields usually hashed by routers to load |> split for ECMP: IP source/destination address, TCP/UDP |> source/destination port; maybe the protocol/next header=20 |field as well. |> |> If you do this, you are essentially spoofing traffic for the host |> originating the flow. I'm sure the security review comments for this |> will make for entertaining reading. |> |> At the very least, you need to ensure that there is an *airtight* |> mechanism for ensuring that the probe traffic can never leak out of =20 |> the |> PCN domain, and that no ICMP traffic can be sent back towards the |> host. | |Let me add that probe traffic (other than for supporting ECMP) seems =20 |only useful when a domain can go from "no congestion" to "must =20 |terminate" through the admission of a very small number of flows. =20 |Otherwise, the gradual admission of regular flows can be used to =20 |determine whether admission should be terminated. In other words, =20 |regular flows can be used to "probe" the domain. | |I question whether domains that require explicit probing mechanisms =20 |fall under the current PCN charter, which focuses on domains that =20 |multiplex a sufficient numbers of flows such that stateless, =20 |statistical mechanisms are effective. | |Explicit probing adds a lot of complexity. The idea behind PCN is to =20 |add a minimal set of mechanisms to a large and busy DiffServ domain, =20 |which would allow this domain to protect the QoS of already-admitted =20 |flows in a best-effort sort of way. Meaning that although flow =20 |termination should be mostly prevented due to admission stop =20 |decisions, there will be no guarantees that no flow will ever be =20 |terminated. PCN is also not a mechanism to squeeze the last ounce of =20 |utilization out of a domain - sufficient overprovisioning remains a =20 |requirement. Because of this, I wonder if PCN needs to support ECMP - =20 |which did not come up during the chartering phase - when it looks =20 |likely that such support will significantly complicate the solution. | |Finally, let me say that I'm worried that the WG seems to have =20 |settled on a mode of working where all the different proposals will =20 |be merged into one. The result is not likely to be a very simple =20 |solution. We have ample experience with solutions that have been =20 |designed in this manner failing to gain any traction, due to their =20 |complexities. | |I'd like to strongly encourage the WG to instead discuss which of the =20 |proposals is the most *simple* one that will fulfill the chartered =20 |goals. We'd like the outcome of the first phase of work to be =20 |something that people will usefully deploy in some domains. Without =20 |demonstrated deployability and use, the need for continued future =20 |work on PCN is questionable. | |Lars | | | _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Oct 01 05:54:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcHz6-00053K-NC; Mon, 01 Oct 2007 05:54:40 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IcHz5-00051p-SF for pcn-confirm+ok@megatron.ietf.org; Mon, 01 Oct 2007 05:54:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcHz5-00051b-GX for pcn@ietf.org; Mon, 01 Oct 2007 05:54:39 -0400 Received: from rsys001x.roke.co.uk ([193.118.201.108]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcHz4-00064L-Pm for pcn@ietf.org; Mon, 01 Oct 2007 05:54:39 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.13.1/8.13.1) with ESMTP id l919sXSb012083; Mon, 1 Oct 2007 10:54:34 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] PCN architecture, revised sub-section on probing Date: Mon, 1 Oct 2007 10:55:02 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN architecture, revised sub-section on probing Thread-Index: AcgCYpbL+nWPqNEsR+i9utUXJcjrLgBpJqag References: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC516@E03MVZ1-UKDY.domain1.systemhost.net><1191003334.15202.61.camel@neutrino> From: "Hancock, Robert" To: "Lars Eggert" , "ext Steven Blake" X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: pcn X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org hi, a comment on probe messages:=20 > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@nokia.com]=20 > Sent: 29 September 2007 07:31 > To: ext Steven Blake > Cc: pcn > Subject: Re: [PCN] PCN architecture, revised sub-section on probing >=20 > On 2007-9-28, at 21:15, ext Steven Blake wrote: > > If a probe packet for a PCN-managed flow is intended to follow the=20 > > same ECMP path as the flow, then the probe packet has to=20 > look exactly=20 > > like flow packets in the header fields usually hashed by routers to=20 > > load split for ECMP: IP source/destination address, TCP/UDP=20 > > source/destination port; maybe the protocol/next header=20 > field as well. > > > > If you do this, you are essentially spoofing traffic for the host=20 > > originating the flow. I'm sure the security review=20 > comments for this=20 > > will make for entertaining reading. > > > > At the very least, you need to ensure that there is an *airtight*=20 > > mechanism for ensuring that the probe traffic can never leak out of=20 > > the PCN domain, and that no ICMP traffic can be sent back=20 > towards the=20 > > host. Having been through a very similar question in the context of another protocol, my feeling is that this level of 'faithfulness' in the=20 probe messages at least is over-ambitious. There are conflicting=20 requirements: - you accept that ECMP can load share on nearly anything, i.e. the interior packet classifiers can look far into the packet for fields=20 to distinguish microflows, but - you rely on egress packet classifiers to look into the packet to=20 find fields to disambiguate probe and real traffic It's hard to think of deployment approaches which would be robust in meeting these requirements. Even in a single deployment, there could be heterogeneous classification capabilities in the interior=20 and edge routers.=20 (For this circumstance at least, it would be nice if there was some guidance or baseline assumption on exactly how fine-grained it is sensible for things like ECMP to be. I'm not sure how practical that is, however.) robert h. >=20 > Let me add that probe traffic (other than for supporting=20 > ECMP) seems only useful when a domain can go from "no=20 > congestion" to "must terminate" through the admission of a=20 > very small number of flows. =20 > Otherwise, the gradual admission of regular flows can be used=20 > to determine whether admission should be terminated. In other=20 > words, regular flows can be used to "probe" the domain. >=20 > I question whether domains that require explicit probing=20 > mechanisms fall under the current PCN charter, which focuses=20 > on domains that multiplex a sufficient numbers of flows such=20 > that stateless, statistical mechanisms are effective. >=20 > Explicit probing adds a lot of complexity. The idea behind=20 > PCN is to add a minimal set of mechanisms to a large and busy=20 > DiffServ domain, which would allow this domain to protect the=20 > QoS of already-admitted flows in a best-effort sort of way.=20 > Meaning that although flow termination should be mostly=20 > prevented due to admission stop decisions, there will be no=20 > guarantees that no flow will ever be terminated. PCN is also=20 > not a mechanism to squeeze the last ounce of utilization out=20 > of a domain - sufficient overprovisioning remains a=20 > requirement. Because of this, I wonder if PCN needs to=20 > support ECMP - which did not come up during the chartering=20 > phase - when it looks likely that such support will=20 > significantly complicate the solution. >=20 > Finally, let me say that I'm worried that the WG seems to=20 > have settled on a mode of working where all the different=20 > proposals will be merged into one. The result is not likely=20 > to be a very simple solution. We have ample experience with=20 > solutions that have been designed in this manner failing to=20 > gain any traction, due to their complexities. >=20 > I'd like to strongly encourage the WG to instead discuss=20 > which of the proposals is the most *simple* one that will=20 > fulfill the chartered goals. We'd like the outcome of the=20 > first phase of work to be something that people will usefully=20 > deploy in some domains. Without demonstrated deployability=20 > and use, the need for continued future work on PCN is questionable. >=20 > Lars >=20 >=20 >=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Oct 01 06:30:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcIX2-0002Y9-S6; Mon, 01 Oct 2007 06:29:44 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IcIX1-0002WM-7r for pcn-confirm+ok@megatron.ietf.org; Mon, 01 Oct 2007 06:29:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcIX0-0002VK-RG for pcn@ietf.org; Mon, 01 Oct 2007 06:29:42 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcIWz-000750-VL for pcn@ietf.org; Mon, 01 Oct 2007 06:29:42 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Mon, 1 Oct 2007 12:29:40 +0200 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Oct 2007 12:29:40 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PCN] PCN architecture, revised sub-section on probing X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 1 Oct 2007 12:29:39 +0200 Message-Id: <1B6169C658325341A3B8066E23919E1C0DE846@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC516@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN architecture, revised sub-section on probing thread-index: AcfaCZ+BOedo9lzYRa+g2kHgUi9IgAggHadAAQwNp+AAUwip8AB6vy9AAIWmXOA= From: "Geib, Ruediger" To: X-OriginalArrivalTime: 01 Oct 2007 10:29:40.0358 (UTC) FILETIME=[F94EE260:01C80415] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2b428fb4265163ba7f2ac2af0ebfcf00 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0636828272==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0636828272== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C80415.F8FA8CDC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C80415.F8FA8CDC Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Phil, =20 My replies in line, marked as [RG_later]. =20 Regards, =20 Ruediger =20 -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: Friday, September 28, 2007 7:30 PM To: Geib, Rudiger Cc: pcn@ietf.org Subject: RE: [PCN] PCN architecture, revised sub-section on probing Ruediger, =20 Follow-ups (further questions!) in-line on each of your 3 points=20 =20 [RG _earlier] - the discussion on the decision when to apply probing misses one important aspect, at least if=20 you look at a single domain: probing is only required if any pre-congestion occurs within this=20 domain. If there's no pre congested link within a domain, no probing is required within this=20 domain.=20 =20 [phil] I slightly re-phrased the first bullet (the second bullet is unaltered), so the text now says: =20 Probing is useful or even essential under the following conditions: =20 o when an ingress-egress-aggregate carries no traffic (or too little traffic for the PCN-egress-node to accurately make the "measurements of PCN-traffic" that are required for an admission decision), but the traffic levels on other ingress-egress-aggregates are so high that a new flow shouldn't be admitted on the 'empty' ingress-egress-aggregate. Probing is useful to check this. o in the presence of multipath routing (ECMP) between the PCN-boundary-nodes, when some paths are pre-congested there may be other paths which aren't pre-congested. Probing is useful to determine whether the new flow would follow a path that isn't pre-congested and hence can be admitted. =20 I think what's written implies that it may not always be possible to know whether there's any (relevant) pre-congestion or none - so there's an argument for probing in such times of doubt to discover what the situation really is (if it turns out that there isn't any pre-congestion then, as you say, in some ways the probing hasn't proved to be useful). I think the tweaked text above captures this, but please suggest any mods to make it clearer (or disagree!)=20 =20 [RG_later] suggestion last sentence first bullet point: "...Probing may be useful to check this." Probing results in more complex edge system implementations and I'm not convinced that it provides benefits. As mentioned in another thread, if PCN provides the expected service quality for admitted flows also without probing, I prefer not to probe for the first round of PCN specs. =20 =20 [RG _earlier } - given that probing is only applied within a domain, if there's pre-congestion on any link, then=20 the only purpose of probing is to find out, whether traffic from the particular ingress to a=20 desired egress would contribute to this pre-congestion. The probing flow then should be=20 designed to ensure that packets of the probing flow are marked (and if interpretation is=20 to be as simple as possible: marked probing packets mean no admission).=20 =20 [phil] I'm not quite sure what you mean by "designed to ensure that packets of the probing flow are marked". The section currently says that probe pkts are handled in the same way as (ordinary data) PCN-pkts [*]. I think you may be suggesting something different, that probing pkts should be preferentially PCN-marked?=20 [*] incidentally, I'll tweak the text to add something like "in terms of pkt scheduling/forwarding and PCN-marking" ; for pkt dropping it may be arguable you should preferentially drop probes to ease DoS worries? =20 Re: "interpretation is to be as simple as possible: marked probing packets mean no admission" - I think this is too solution-space for this Architecture draft (presumably there may be different options, eg block call if the single probe pkt is marked, if at least 2 out of 100 marked, etc)=20 =20 [RG_later] Probing needs to be done at rate with a packet size and during a determined probing intervall. The receiver needs to know, which packet is the first and which is the last. What I want to say is, "simple" probing works with a single rate/packet size/probing intervall. These are not related the properties of to the flow for whose admission the probing is applied. As the probe flow properties are not related to the real flow properties, admission decisions should be rather simple too. Ehat's the benefit if a node starts to calculate rates of pre-congestion marks for a probe flow whose properties aren't related to the flow to be admitted? To complete my statement: rather that having a measurement function trying to simulate the flow requesting admission more exactly, I prefer to have no measurement functionality. I prefer simple edge nodes. =20 [RG _earlier] - If there's no flow between an ingress and an egress and ECMP is operational within a=20 domain, the ingress may have to signal its intention to probe to an egress. =20 [phil] could you explain your reference to ECMP please? At the moment the doc says that "(if required) Communicate the request that probing is needed - the PCN-egress-node signals to the PCN-ingress-node that probe traffic is needed". But you're suggesting there are particular circumstances when something is needed in the opposite direction?=20 =20 [RG_later]: Please forget the ECMP statement. The PCN ingress node first signals the per flow reservation request to the egress node and then the egress checks, whether any admitted flows from this ingress pass it already. Then the egress requests the ingress to probe. If that's what your text means, it should say so. Or at least it should say, that the egress must learn that there's a new flow to be admitted prior to requesting an ingress to probe. I'd like to avoid probing if there's no need to probe. =20 =20 Thanks! phil =20 =20 ------_=_NextPart_001_01C80415.F8FA8CDC Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Phil,
 
My=20 replies in line, marked as [RG_later].
 
Regards,
 
Ruediger
 
-----Original Message-----
From: = philip.eardley@bt.com=20 [mailto:philip.eardley@bt.com]
Sent: Friday, September 28, = 2007 7:30=20 PM
To: Geib, Rüdiger
Cc: = pcn@ietf.org
Subject:=20 RE: [PCN] PCN architecture, revised sub-section on=20 probing

Ruediger,

 

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

 

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

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

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

 =20 domain. 

 

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

 

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

 

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

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

 

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

 

[RG_later] suggestion last sentence = first bullet=20 point: "...Probing may be useful to check = this." Probing results in=20 more complex edge system implementations and I'm not = convinced that=20 it provides benefits. As mentioned in another thread, if PCN provides = the=20 expected service quality for admitted flows also without probing, I = prefer not=20 to probe for the first round of PCN specs.

 

 

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

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

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

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

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

 

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

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

 

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

 

[RG_later] Probing needs to=20 be done at rate with a packet size and during a determined = probing=20 intervall. The receiver needs to know, which packet is the first and = which is=20 the last. What I want to say is, "simple" probing works with = a=20 single rate/packet size/probing intervall. These are not related the=20 properties of to the flow for whose admission the probing is applied. = As the=20 probe flow properties are not related to the real flow properties, = admission=20 decisions should be rather simple too. Ehat's the benefit if  a = node=20 starts to calculate rates of pre-congestion marks for a probe flow = whose=20 properties aren't related to the flow to be=20 admitted?

To complete my = statement: rather=20 that having a measurement function trying to simulate the flow = requesting=20 admission more exactly, I prefer to have no measurement = functionality. I=20 prefer simple edge nodes.

 

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

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

 

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

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

 

[RG_later]: Please forget the ECMP statement. = The PCN=20 ingress node first signals the per flow reservation request to = the egress=20 node and then the egress checks, whether any admitted = flows=20 from this ingress pass it already. Then the egress requests the = ingress=20 to probe. If that's what your text means, it should say so. Or at = least it=20 should say, that the egress must learn that there's a new flow to be = admitted=20 prior to requesting an ingress to probe. I'd like to avoid probing if = there's=20 no need to probe.

 

 

Thanks!

phil

 

 

------_=_NextPart_001_01C80415.F8FA8CDC-- --===============0636828272== 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 --===============0636828272==-- From pcn-bounces@ietf.org Mon Oct 01 08:09:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcK4x-0003gq-NN; Mon, 01 Oct 2007 08:08:51 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IcK4w-0003gj-AB for pcn-confirm+ok@megatron.ietf.org; Mon, 01 Oct 2007 08:08:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcK4v-0003c2-T7 for pcn@ietf.org; Mon, 01 Oct 2007 08:08:49 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcK4q-0001kJ-Fv for pcn@ietf.org; Mon, 01 Oct 2007 08:08:45 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B417720A61; Mon, 1 Oct 2007 14:08:43 +0200 (CEST) X-AuditID: c1b4fb3c-b1681bb0000007e1-0b-4700e34bd7d2 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 97B1420A28; Mon, 1 Oct 2007 14:08:43 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Oct 2007 14:08:43 +0200 Received: from ericsson.com ([147.214.26.58]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Oct 2007 14:08:43 +0200 Message-ID: <4700E34B.4080000@ericsson.com> Date: Mon, 01 Oct 2007 14:08:43 +0200 From: Lars Westberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hancock, Robert" Subject: Re: [PCN] PCN architecture, revised sub-section on probing References: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC516@E03MVZ1-UKDY.domain1.systemhost.net><1191003334.15202.61.camel@neutrino> In-Reply-To: X-OriginalArrivalTime: 01 Oct 2007 12:08:43.0387 (UTC) FILETIME=[CFA124B0:01C80423] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac Cc: pcn X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0536433173==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0536433173== Content-Type: multipart/alternative; boundary="------------000102040006030708010907" This is a multi-part message in MIME format. --------------000102040006030708010907 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit hi Robert. I think the task is to do something very simplistic and skip the compexity to other solutions. If you want to have something complex, one can use NSIS. I am very worried to go into the complexity swamp. -Lasse Hancock, Robert wrote: > hi, > > a comment on probe messages: > > > -----Original Message----- > > From: Lars Eggert [mailto:lars.eggert@nokia.com] > > Sent: 29 September 2007 07:31 > > To: ext Steven Blake > > Cc: pcn > > Subject: Re: [PCN] PCN architecture, revised sub-section on probing > > > > On 2007-9-28, at 21:15, ext Steven Blake wrote: > > > If a probe packet for a PCN-managed flow is intended to follow the > > > same ECMP path as the flow, then the probe packet has to > > look exactly > > > like flow packets in the header fields usually hashed by routers to > > > load split for ECMP: IP source/destination address, TCP/UDP > > > source/destination port; maybe the protocol/next header > > field as well. > > > > > > If you do this, you are essentially spoofing traffic for the host > > > originating the flow. I'm sure the security review > > comments for this > > > will make for entertaining reading. > > > > > > At the very least, you need to ensure that there is an *airtight* > > > mechanism for ensuring that the probe traffic can never leak out of > > > the PCN domain, and that no ICMP traffic can be sent back > > towards the > > > host. > > Having been through a very similar question in the context of another > protocol, my feeling is that this level of 'faithfulness' in the > probe messages at least is over-ambitious. There are conflicting > requirements: > > - you accept that ECMP can load share on nearly anything, i.e. the > interior packet classifiers can look far into the packet for fields > to distinguish microflows, but > - you rely on egress packet classifiers to look into the packet to > find fields to disambiguate probe and real traffic > > It's hard to think of deployment approaches which would be robust > in meeting these requirements. Even in a single deployment, there > could be heterogeneous classification capabilities in the interior > and edge routers. > > (For this circumstance at least, it would be nice if there was some > guidance or baseline assumption on exactly how fine-grained it is > sensible for things like ECMP to be. I'm not sure how practical > that is, however.) > > robert h. > > > > > Let me add that probe traffic (other than for supporting > > ECMP) seems only useful when a domain can go from "no > > congestion" to "must terminate" through the admission of a > > very small number of flows. > > Otherwise, the gradual admission of regular flows can be used > > to determine whether admission should be terminated. In other > > words, regular flows can be used to "probe" the domain. > > > > I question whether domains that require explicit probing > > mechanisms fall under the current PCN charter, which focuses > > on domains that multiplex a sufficient numbers of flows such > > that stateless, statistical mechanisms are effective. > > > > Explicit probing adds a lot of complexity. The idea behind > > PCN is to add a minimal set of mechanisms to a large and busy > > DiffServ domain, which would allow this domain to protect the > > QoS of already-admitted flows in a best-effort sort of way. > > Meaning that although flow termination should be mostly > > prevented due to admission stop decisions, there will be no > > guarantees that no flow will ever be terminated. PCN is also > > not a mechanism to squeeze the last ounce of utilization out > > of a domain - sufficient overprovisioning remains a > > requirement. Because of this, I wonder if PCN needs to > > support ECMP - which did not come up during the chartering > > phase - when it looks likely that such support will > > significantly complicate the solution. > > > > Finally, let me say that I'm worried that the WG seems to > > have settled on a mode of working where all the different > > proposals will be merged into one. The result is not likely > > to be a very simple solution. We have ample experience with > > solutions that have been designed in this manner failing to > > gain any traction, due to their complexities. > > > > I'd like to strongly encourage the WG to instead discuss > > which of the proposals is the most *simple* one that will > > fulfill the chartered goals. We'd like the outcome of the > > first phase of work to be something that people will usefully > > deploy in some domains. Without demonstrated deployability > > and use, the need for continued future work on PCN is questionable. > > > > Lars > > > > > > > > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn > --------------000102040006030708010907 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit hi Robert.

I think the task is to do something very simplistic and skip the compexity to other solutions.
 If you want to have something complex, one can use NSIS. I am very worried to go into the complexity swamp.


-Lasse

Hancock, Robert wrote:
RE: [PCN] PCN architecture, revised sub-section on probing

hi,

a comment on probe messages:

> -----Original Message-----
> From: Lars Eggert [mailto:lars.eggert@nokia.com]
> Sent: 29 September 2007 07:31
> To: ext Steven Blake
> Cc: pcn
> Subject: Re: [PCN] PCN architecture, revised sub-section on probing
>
> On 2007-9-28, at 21:15, ext Steven Blake wrote:
> > If a probe packet for a PCN-managed flow is intended to follow the
> > same ECMP path as the flow, then the probe packet has to
> look exactly
> > like flow packets in the header fields usually hashed by routers to
> > load split for ECMP: IP source/destination address, TCP/UDP
> > source/destination port; maybe the protocol/next header
> field as well.
> >
> > If you do this, you are essentially spoofing traffic for the host
> > originating the flow.  I'm sure the security review
> comments for this
> > will make for entertaining reading.
> >
> > At the very least, you need to ensure that there is an *airtight*
> > mechanism for ensuring that the probe traffic can never leak out of
> > the PCN domain, and that no ICMP traffic can be sent back
> towards the
> > host.

Having been through a very similar question in the context of another
protocol, my feeling is that this level of 'faithfulness' in the
probe messages at least is over-ambitious. There are conflicting
requirements:

- you accept that ECMP can load share on nearly anything, i.e. the
interior packet classifiers can look far into the packet for fields
to distinguish microflows, but
- you rely on egress packet classifiers to look into the packet to
find fields to disambiguate probe and real traffic

It's hard to think of deployment approaches which would be robust
in meeting these requirements. Even in a single deployment, there
could be heterogeneous classification capabilities in the interior
and edge routers.

(For this circumstance at least, it would be nice if there was some
guidance or baseline assumption on exactly how fine-grained it is
sensible for things like ECMP to be. I'm not sure how practical
that is, however.)

robert h.

>
> Let me add that probe traffic (other than for supporting
> ECMP) seems only useful when a domain can go from "no
> congestion" to "must terminate" through the admission of a
> very small number of flows. 
> Otherwise, the gradual admission of regular flows can be used
> to determine whether admission should be terminated. In other
> words, regular flows can be used to "probe" the domain.
>
> I question whether domains that require explicit probing
> mechanisms fall under the current PCN charter, which focuses
> on domains that multiplex a sufficient numbers of flows such
> that stateless, statistical mechanisms are effective.
>
> Explicit probing adds a lot of complexity. The idea behind
> PCN is to add a minimal set of mechanisms to a large and busy
> DiffServ domain, which would allow this domain to protect the
> QoS of already-admitted flows in a best-effort sort of way.
> Meaning that although flow termination should be mostly
> prevented due to admission stop decisions, there will be no
> guarantees that no flow will ever be terminated. PCN is also
> not a mechanism to squeeze the last ounce of utilization out
> of a domain - sufficient overprovisioning remains a
> requirement. Because of this, I wonder if PCN needs to
> support ECMP - which did not come up during the chartering
> phase - when it looks likely that such support will
> significantly complicate the solution.
>
> Finally, let me say that I'm worried that the WG seems to
> have settled on a mode of working where all the different
> proposals will be merged into one. The result is not likely
> to be a very simple solution. We have ample experience with
> solutions that have been designed in this manner failing to
> gain any traction, due to their complexities.
>
> I'd like to strongly encourage the WG to instead discuss
> which of the proposals is the most *simple* one that will
> fulfill the chartered goals. We'd like the outcome of the
> first phase of work to be something that people will usefully
> deploy in some domains. Without demonstrated deployability
> and use, the need for continued future work on PCN is questionable.
>
> Lars
>
>
>


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

--------------000102040006030708010907-- --===============0536433173== 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 --===============0536433173==-- From pcn-bounces@ietf.org Mon Oct 01 09:57:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcLlr-0001Sh-H4; Mon, 01 Oct 2007 09:57:15 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IcLlq-0001ST-9L for pcn-confirm+ok@megatron.ietf.org; Mon, 01 Oct 2007 09:57:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcLlp-0001SL-VP for pcn@ietf.org; Mon, 01 Oct 2007 09:57:13 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcLlk-0002Ro-Lu for pcn@ietf.org; Mon, 01 Oct 2007 09:57:13 -0400 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l91DuP4e027698; Mon, 1 Oct 2007 08:56:25 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Oct 2007 08:56:25 -0500 Received: from [147.117.169.143] ([147.117.169.143]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Oct 2007 08:56:25 -0500 Subject: RE: [PCN] PCN architecture, revised sub-section on probing From: Steven Blake To: Georgios Karagiannis In-Reply-To: References: Content-Type: text/plain Organization: Ericsson IP Infrastructure Date: Mon, 01 Oct 2007 09:56:24 -0400 Message-Id: <1191246984.4024.0.camel@neutrino> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Oct 2007 13:56:25.0090 (UTC) FILETIME=[DB1AC620:01C80432] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: pcn X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org On Sat, 2007-09-29 at 09:19 +0000, Georgios Karagiannis wrote: > Hi Steven > > Regarding the below comment: > > > On 9/28/2007, "Steven Blake" wrote: > > >If a probe packet for a PCN-managed flow is intended to follow the same > >ECMP path as the flow, then the probe packet has to look exactly like > >flow packets in the header fields usually hashed by routers to load > >split for ECMP: IP source/destination address, TCP/UDP > >source/destination port; maybe the protocol/next header field as well. > > > >If you do this, you are essentially spoofing traffic for the host > >originating the flow. I'm sure the security review comments for this > >will make for entertaining reading. > > > >At the very least, you need to ensure that there is an *airtight* > >mechanism for ensuring that the probe traffic can never leak out of the > >PCN domain, and that no ICMP traffic can be sent back towards the > >host. > > Georgios: You are right about the security implications, therefore a > requirement that has to hold is that the (end)node that initiates the > flow should maintain security associations with the PCN-ingress node > that initiates probing. Please elaborate. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven Blake Ericsson/Redback Networks +1 919-472-9913 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Oct 01 11:17:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcN15-0006kv-6f; Mon, 01 Oct 2007 11:17:03 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IcN13-0006id-PB for pcn-confirm+ok@megatron.ietf.org; Mon, 01 Oct 2007 11:17:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcN13-0006hR-FS for pcn@ietf.org; Mon, 01 Oct 2007 11:17:01 -0400 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcN0u-0003gK-8j for pcn@ietf.org; Mon, 01 Oct 2007 11:16:58 -0400 Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Oct 2007 16:16:36 +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] FW: I-D ACTION:draft-babiarz-pcn-3sm-00.txt Date: Mon, 1 Oct 2007 16:16:35 +0100 Message-ID: <66C55C26FA491C42A9C9BB62A376DAFF05FEA8@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <9671A92C3C8B5744BC97F855F7CB64651115D555@zcarhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] FW: I-D ACTION:draft-babiarz-pcn-3sm-00.txt Thread-Index: Ace9iWWi634qt9N+RbasyEGXvJ9y5AAC1p1wEan/iSA= From: To: , X-OriginalArrivalTime: 01 Oct 2007 15:16:36.0484 (UTC) FILETIME=[0EEB3C40:01C8043E] X-Spam-Score: -0.1 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Joe (All) Sorry about the late comments but my attention was recently drawn to this draft and in particular its approach to simulate threshold marking. Appendix A.6 suggests that a single rate three colour marker can be used to perform threshold marking. I think this is not true. If you configure the srTCM in the way suggested it will mark exactly the same packets as a single token bucket of length MBS doing tail marking. It is true that the fill level of the E bucket will correctly track the fill level of the larger token bucket (of length TB.size) that we are trying to emulate. However, the fill level of the E bucket does not affect the marking which will be done if and only if the C bucket is at its tail. Thus the setup becomes equivalent to the C bucket alone. HTH Ben Strulo > -----Original Message----- > From: Jozef Babiarz [mailto:babiarz@nortel.com]=20 > Sent: 03 July 2007 18:18 > To: pcn@ietf.org > Subject: [PCN] FW: I-D ACTION:draft-babiarz-pcn-3sm-00.txt >=20 >=20 > Hi all, > In an email below there is a link to 00 version of pcn-3sm=20 > draft that defines metering and marking for admission control=20 > and flow termination. We call it three state PCN marking=20 > because there are three conditions, packets are not marked,=20 > packets marked to indicate that admission of additional flows=20 > should be stopped and finally condition where flows are=20 > marked to indicate that termination is needed. This draft=20 > incorporates the metering and marking approach for flow=20 > termination that was defined in=20 > draft-babiarz-pcn-explicit-marking-00.=20 >=20 > Simulation results for the proposed "AR-metering and=20 > AS-re-marking" and "SR-metering and ET-re-marking" will be=20 > published in a separate draft. >=20 > Regards, Joe > email:babiarz@nortel.com > Telephone:613-763-6098 > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: July 3, 2007 11:15 AM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-babiarz-pcn-3sm-00.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. >=20 >=20 > Title : Three State PCN Marking > Author(s) : J. Babiarz, et al. > Filename : draft-babiarz-pcn-3sm-00.txt > Pages : 24 > Date : 2007-7-3 > =09 > This document proposes metering and marking mechanisms for PCN- > enabled nodes to label packets with pre-congestion=20 > information. The > marker marks all PCN packets with an admission-stop (AS)=20 > codepoint if > the PCN traffic rate on a link exceeds its admissible rate (AR) and > when it exceeds its supportable rate (SR), it marks some of those > packets exceeding SR with an excess-traffic (ET) codepoint. The > flows with ET-marked packets will be terminated until the aggregate > PCN traffic on the path decreases below its SR. This document > proposes metering and marking mechanisms for these objectives. >=20 >=20 > A URL for this Internet-Draft is:=20 > http://www.ietf.org/internet-drafts/draft-babiarz-pcn-3sm-00.txt >=20 > To remove yourself from the I-D Announcement list, send a message to=20 > i-d-announce-request@ietf.org with the word unsubscribe in=20 > the body of=20 > the message.=20 > You can also visit=20 > https://www1.ietf.org/mailman/listinfo/I-D-announce=20 > to change your subscription settings. >=20 > Internet-Drafts are also available by anonymous FTP. Login with the=20 > username "anonymous" and a password of your e-mail address. After=20 > logging in, type "cd internet-drafts" and then=20 > "get draft-babiarz-pcn-3sm-00.txt". >=20 > A list of Internet-Drafts directories can be found in=20 > http://www.ietf.org/shadow.html=20 > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-babiarz-pcn-3sm-00.txt". > =09 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant=20 > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. >=20 > Below is the data which will enable a MIME compliant mail=20 > reader implementation to automatically retrieve the ASCII=20 > version of the Internet-Draft. >=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Oct 01 21:26:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcWWX-0005GX-DK; Mon, 01 Oct 2007 21:26:09 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IcWWU-0005Co-OL for pcn-confirm+ok@megatron.ietf.org; Mon, 01 Oct 2007 21:26:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcWWR-00058V-2T for pcn@ietf.org; Mon, 01 Oct 2007 21:26:04 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcWWK-0000bY-TA for pcn@ietf.org; Mon, 01 Oct 2007 21:26:03 -0400 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l921Pfi03018; Tue, 2 Oct 2007 01:25:41 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] PCN architecture, revised sub-section on probing Date: Mon, 1 Oct 2007 21:25:40 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB6465126A2453@zcarhxm1.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN architecture, revised sub-section on probing thread-index: AcgCYq2N/4XYbk6NRD60LJIzczzgBQCKeb2w References: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC516@E03MVZ1-UKDY.domain1.systemhost.net> <1191003334.15202.61.camel@neutrino> From: "Jozef Babiarz" To: "Lars Eggert" , "ext Steven Blake" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: pcn X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Issue with probing. First, I believe that the PCN architectural draft should discuss probing as it pertains to PCN. I also think that it should articulate what problems probing is trying to solve. The architectural draft should position (which I think it does) that probing should be used when needed as there are deployment scenarios where probing may not be needed.=20 Yes, probing between PCN boundary nodes needs to be designed carefully as there are security concerns that need to be addressed. The design of the PCN probing mechanism needs to be document in a stand alone draft so that it can be used in a PCN solution when needed. This means that not every PCN domain needs to support probing but some PCN domains may choose to support probing because it solves specific configuration issues (ECMP, etc.) that are important to them.=20 I believe that the probing issues needs to be address by the PCN group in a detailed proposal document in the draft and present to the group. Once we have a good understanding of the proposed probing solution then we can pass judgment on complexity, security, and performance.=20 Regards, Joe email:babiarz@nortel.com Telephone:613-763-6098 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Oct 02 05:00:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icdbw-0002vx-8F; Tue, 02 Oct 2007 05:00:12 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Icdbv-0002vc-Gs for pcn-confirm+ok@megatron.ietf.org; Tue, 02 Oct 2007 05:00:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icdbv-0002vE-7E for pcn@ietf.org; Tue, 02 Oct 2007 05:00:11 -0400 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Icdbo-0002Sn-UW for pcn@ietf.org; Tue, 02 Oct 2007 05:00:11 -0400 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 l928xa0m010328; Tue, 2 Oct 2007 10:59:53 +0200 (MEST) From: "Georgios Karagiannis" To: "'Jozef Babiarz'" , "'Lars Eggert'" , "'ext Steven Blake'" References: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC516@E03MVZ1-UKDY.domain1.systemhost.net><1191003334.15202.61.camel@neutrino> <9671A92C3C8B5744BC97F855F7CB6465126A2453@zcarhxm1.corp.nortel.com> Subject: RE: [PCN] PCN architecture, revised sub-section on probing Date: Tue, 2 Oct 2007 10:59:30 +0200 Message-ID: <001701c804d2$8f7b60d0$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.3138 In-Reply-To: <9671A92C3C8B5744BC97F855F7CB6465126A2453@zcarhxm1.corp.nortel.com> Thread-Index: AcgCYq2N/4XYbk6NRD60LJIzczzgBQCKeb2wABF2CVA= X-Spam-Score: 0.088 () 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, 02 Oct 2007 10:59:53 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: 'pcn' X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Dear all I agree with the solution proposed by Jozef on the probing issue! Best regards, Georgios > -----Original Message----- > From: Jozef Babiarz [mailto:babiarz@nortel.com] > Sent: dinsdag 2 oktober 2007 3:26 > To: Lars Eggert; ext Steven Blake > Cc: pcn > Subject: RE: [PCN] PCN architecture, revised sub-section on probing > > Issue with probing. > > First, I believe that the PCN architectural draft should > discuss probing as it pertains to PCN. I also think that it > should articulate what problems probing is trying to solve. > The architectural draft should position (which I think it > does) that probing should be used when needed as there are > deployment scenarios where probing may not be needed. > > Yes, probing between PCN boundary nodes needs to be designed > carefully as there are security concerns that need to be > addressed. The design of the PCN probing mechanism needs to > be document in a stand alone draft so that it can be used in > a PCN solution when needed. This means that not every PCN > domain needs to support probing but some PCN domains may > choose to support probing because it solves specific > configuration issues (ECMP, etc.) that are important to them. > > I believe that the probing issues needs to be address by the > PCN group in a detailed proposal document in the draft and > present to the group. > Once we have a good understanding of the proposed probing > solution then we can pass judgment on complexity, security, > and performance. > > Regards, Joe > email:babiarz@nortel.com > Telephone:613-763-6098 > > > > _______________________________________________ > 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 Oct 02 05:24:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icdzq-00076U-7k; Tue, 02 Oct 2007 05:24:54 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Icdzo-00074g-MO for pcn-confirm+ok@megatron.ietf.org; Tue, 02 Oct 2007 05:24:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icdzo-00074X-Cr for pcn@ietf.org; Tue, 02 Oct 2007 05:24:52 -0400 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 1Icdzi-0003Bp-26 for pcn@ietf.org; Tue, 02 Oct 2007 05:24:52 -0400 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 41AAFAF92; Tue, 2 Oct 2007 11:24:30 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 33FEEB012; Tue, 2 Oct 2007 11:24:30 +0200 (CEST) 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 CFB5BAF92; Tue, 2 Oct 2007 11:24:26 +0200 (CEST) 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 l929OQh21621; Tue, 2 Oct 2007 11:24:26 +0200 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 70B4D6F591; Tue, 2 Oct 2007 11:17:31 +0200 (CEST) Message-ID: <47020D98.3000102@informatik.uni-wuerzburg.de> Date: Tue, 02 Oct 2007 11:21:28 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jozef Babiarz Subject: Re: [PCN] PCN architecture, revised sub-section on probing References: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC516@E03MVZ1-UKDY.domain1.systemhost.net> <1191003334.15202.61.camel@neutrino> <9671A92C3C8B5744BC97F855F7CB6465126A2453@zcarhxm1.corp.nortel.com> In-Reply-To: <9671A92C3C8B5744BC97F855F7CB6465126A2453@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: 4adaf050708fb13be3316a9eee889caa Cc: pcn X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org I agree. Michael Jozef Babiarz wrote: > Issue with probing. > > First, I believe that the PCN architectural draft should discuss probing > as it pertains to PCN. I also think that it should articulate what > problems probing is trying to solve. The architectural draft should > position (which I think it does) that probing should be used when needed > as there are deployment scenarios where probing may not be needed. > > Yes, probing between PCN boundary nodes needs to be designed carefully > as there are security concerns that need to be addressed. The design of > the PCN probing mechanism needs to be document in a stand alone draft so > that it can be used in a PCN solution when needed. This means that not > every PCN domain needs to support probing but some PCN domains may > choose to support probing because it solves specific configuration > issues (ECMP, etc.) that are important to them. > > I believe that the probing issues needs to be address by the PCN group > in a detailed proposal document in the draft and present to the group. > Once we have a good understanding of the proposed probing solution then > we can pass judgment on complexity, security, and performance. > > Regards, Joe > email:babiarz@nortel.com > Telephone:613-763-6098 > > > > _______________________________________________ > 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 Wed Oct 03 11:14:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id5vH-0005Yh-Qa; Wed, 03 Oct 2007 11:14:03 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Id5vE-0005Y2-Pv for pcn-confirm+ok@megatron.ietf.org; Wed, 03 Oct 2007 11:14:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id5vE-0005Xu-GD for pcn@ietf.org; Wed, 03 Oct 2007 11:14:00 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Id5v7-0000Jj-G4 for pcn@ietf.org; Wed, 03 Oct 2007 11:14:00 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l93FDj3g026749; Wed, 3 Oct 2007 18:13:51 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Oct 2007 18:13:46 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Oct 2007 18:13:42 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Oct 2007 18:13:42 +0300 Received: from [192.1.118.100] (daec-linuxvpn05890.americas.nokia.com [10.241.58.90]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l93FDdRh017877; Wed, 3 Oct 2007 18:13:39 +0300 In-Reply-To: <9671A92C3C8B5744BC97F855F7CB6465126A2453@zcarhxm1.corp.nortel.com> References: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC516@E03MVZ1-UKDY.domain1.systemhost.net> <1191003334.15202.61.camel@neutrino> <9671A92C3C8B5744BC97F855F7CB6465126A2453@zcarhxm1.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: Lars Eggert Subject: Re: [PCN] PCN architecture, revised sub-section on probing Date: Wed, 3 Oct 2007 11:05:51 -0400 To: ext Jozef Babiarz X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 03 Oct 2007 15:13:42.0319 (UTC) FILETIME=[FBEF43F0:01C805CF] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: pcn X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2017933357==" Errors-To: pcn-bounces@ietf.org --===============2017933357== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-40-515870548; protocol="application/pkcs7-signature" --Apple-Mail-40-515870548 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, On 2007-10-2, at 4:25, ext Jozef Babiarz wrote: > First, I believe that the PCN architectural draft should discuss > probing > as it pertains to PCN. I also think that it should articulate what > problems probing is trying to solve. The architectural draft should > position (which I think it does) that probing should be used when > needed > as there are deployment scenarios where probing may not be needed. adding probing functionality to PCN - even as an optional component - is a very significant step. It changes the model of PCN from a reactive one, where the _egress_ monitors congestion levels and responds to imminent congestion, to a proactive one, where the _ingress_ determines whether a path can support a new flow. Similarly, it changes PCN from an optimistic mechanism, where flows are admitted until congestion is imminent, to a pessimistic one, where flows aren't admitted until the path has been probed. These are fundamentally different approaches, and designing an architecture that supports both will add complexity. I personally remain unconvinced that these complications have been sufficiently motivated. > Yes, probing between PCN boundary nodes needs to be designed carefully > as there are security concerns that need to be addressed. It's not only security. Probing adds at least several roundtrips of delay, so that a sufficient volume of probe traffic can be sent to determine whether the path can support a subsequent flow. Also, it is unclear how the probe traffic is being prevented from negatively affecting regular flows. Without such mechanisms, what's the benefit over simply admitting the new flow? Etc. There are so many open questions around such a mechanism that I question whether the IETF is the right place for this discussion. As far as I'm aware there is no other Internet protocol that uses something similar to probing. > The design of > the PCN probing mechanism needs to be document in a stand alone > draft so > that it can be used in a PCN solution when needed. It's too early to discuss where probing should be described. > This means that not > every PCN domain needs to support probing but some PCN domains may > choose to support probing because it solves specific configuration > issues (ECMP, etc.) that are important to them. The need for probing hasn't been sufficiently motivated. It remains unclear what the benefits are, and it it certainly isn't part of the PCN mechanisms that are outlined in the current charter. > I believe that the probing issues needs to be address by the PCN group > in a detailed proposal document in the draft and present to the group. > Once we have a good understanding of the proposed probing solution > then > we can pass judgment on complexity, security, and performance. I disagree. The WG should discuss the simplest possible solution that will fullfil the chartered goals. I can't stress enough that simplicity is key. It's perfectly OK if the initial PCN solution cannot support domains that use ECMP or don't have a lot of statistical multiplexing. As long as it offers sufficient benefit to some domains such that it will see deployment and use, it can always be extended later. (Heck, if PCN offers sufficient benefit, domains may end up turning off ECMP to run PCN.) Finally, it's not only whether or not PCN needs probing. As I said in my last email, I'm worried that the WG generally seems to have settled on a mode of working where all the different proposals and ideas will be merged into one. The result is not likely to be a very simple solution. We have ample experience with solutions that have been designed in this manner failing to gain any traction, due to their complexities. Merging all proposals into one is a feel-good approach that guarantees that there won't be any losers - all proposals live on in some form - but it doesn't guarantee that the merged outcome will be simple, usable and deployable. As I've said before, I'd like to strongly encourage the WG to instead discuss which of the proposals is the best basis for a *simple* solution that will fulfill the chartered goals. We'd like the outcome of the first phase of work to be something that people will usefully deploy in some domains. Without demonstrated deployability and use, the need for continued future work on PCN is questionable. Lars --Apple-Mail-40-515870548 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzEwMDMxNTA1NTJaMCMGCSqGSIb3DQEJBDEWBBRQo9FSyxByYbVx GWSEuGz43/RFGjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAs1OmYgIVsZZoKToEKUHjF9i7Gsm0Cm5VQ5ZoJUEtmp1j7QpfFitT zn+gqNalQrc+b854DfJ+Sl1sYs/uK9ECEeRFrjgmUztopSI6LV3EaxGcLnL8HEDa4ZCul1bTukzs imSQRAv0QkkPk8tBUg6QPG8EJ2A4HPERykV2OeCQsbyxi7GUbovkR8Q0roUObueNHe5RoyBblYX0 cal/h2pE/fanBvf/mWB+tPHVf/xMngi1rKWhes80qW8lMhHCHx5iu3C6jF/ZP9CtlcVcVuhlIBKe o4IVAyOn9/930Tnmi9aMTPEH8B5NgS3k9nMomH9c5p/69e5wruq0vrmMQPZ89AAAAAAAAA== --Apple-Mail-40-515870548-- --===============2017933357== 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 --===============2017933357==-- From pcn-bounces@ietf.org Wed Oct 03 12:52:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id7Rz-0007IO-K5; Wed, 03 Oct 2007 12:51:55 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Id7Ry-0007IB-LA for pcn-confirm+ok@megatron.ietf.org; Wed, 03 Oct 2007 12:51:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id7Ry-0007I3-B3 for pcn@ietf.org; Wed, 03 Oct 2007 12:51:54 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Id7Rs-0003vu-3e for pcn@ietf.org; Wed, 03 Oct 2007 12:51:54 -0400 X-IronPort-AV: E=Sophos;i="4.21,225,1188792000"; d="scan'208";a="72874650" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 03 Oct 2007 12:51:33 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l93GpWDG004875; Wed, 3 Oct 2007 12:51:32 -0400 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 l93GpDdU021390; Wed, 3 Oct 2007 16:51:32 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Oct 2007 12:51:29 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] PCN architecture, revised sub-section on probing Date: Wed, 3 Oct 2007 12:51:27 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN architecture, revised sub-section on probing Thread-Index: AcgF0JVlYxoOoEQmRpeSHyNIsxDlMQAC08hw From: "Anna Charny (acharny)" To: "Lars Eggert" , "ext Jozef Babiarz" X-OriginalArrivalTime: 03 Oct 2007 16:51:29.0165 (UTC) FILETIME=[A4D8EBD0:01C805DD] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6587; t=1191430292; x=1192294292; 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=20architecture, =20revised=20sub-section=2 0on=20probing |Sender:=20 |To:=20=22Lars=20Eggert=22=20, =0A=20=20=20=20=20=2 0=20=20=22ext=20Jozef=20Babiarz=22=20; bh=WF2dkdInPLI95fI6JGktqn0kEZ2zPrhSFwPhv5HUcI8=; b=YuDBtO6cOCSydGD7sTuj+Dzwi0T1wSVAtGGmg8b42iHWlg13niQgzaIRTK023VG0grO2uDty V9rnFdxSd7M9phlrAM4Y0HuycX+N5AMvLfHwDEVid5CwO/aFwo53VGFo; Authentication-Results: rtp-dkim-1; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: pcn X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Lars and all, Lars, I do not really see that the WG is trying to come up with a solution that encompasses all proposals. While it is true that at the moment the architecture draft lists a number of options, a decision on how to narrow down these options indeed needs to be made, IMHO. =20 We have started work on the document that does functional and algorithmic comparison of various options, with a vew to provide input to the decision on which options would go into the initial PCN WG work, and which could be delayed. We hope to present a draft the the list early November, and certainly in time for the new draft deadline. It would be ideal to also have a thorough performance comparison as well. While a number of steps to that effect have been taken by various simulation efforts, it is not easy to compare simulation results done in different environments and frequently under different assumptions. We are trying our best to bridge that gap, but it remains to be the case that some algorithms/approaches have been subject to more scrutiny than others. As to probing, I agree that the initial solution/WG output may be viable without probing at all. However, as there is a possibly significant benefit (and indeed also a possibly significant additional complexity) that probing might bring, I do not see any harm discussing probing in the WG - as long as it does not delay milestones further. Anna=20 > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@nokia.com]=20 > Sent: Wednesday, October 03, 2007 11:06 AM > To: ext Jozef Babiarz > Cc: pcn > Subject: Re: [PCN] PCN architecture, revised sub-section on probing >=20 > Hi, >=20 > On 2007-10-2, at 4:25, ext Jozef Babiarz wrote: > > First, I believe that the PCN architectural draft should discuss=20 > > probing as it pertains to PCN. I also think that it should=20 > articulate=20 > > what problems probing is trying to solve. The architectural draft=20 > > should position (which I think it does) that probing should be used=20 > > when needed as there are deployment scenarios where probing=20 > may not be=20 > > needed. >=20 > adding probing functionality to PCN - even as an optional=20 > component - is a very significant step. It changes the model=20 > of PCN from a reactive one, where the _egress_ monitors=20 > congestion levels and responds to imminent congestion, to a=20 > proactive one, where the _ingress_ determines whether a path=20 > can support a new flow. =20 > Similarly, it changes PCN from an optimistic mechanism, where=20 > flows are admitted until congestion is imminent, to a=20 > pessimistic one, where flows aren't admitted until the path=20 > has been probed. These are fundamentally different=20 > approaches, and designing an architecture that supports both=20 > will add complexity. I personally remain unconvinced that=20 > these complications have been sufficiently motivated. >=20 > > Yes, probing between PCN boundary nodes needs to be=20 > designed carefully=20 > > as there are security concerns that need to be addressed. >=20 > It's not only security. Probing adds at least several=20 > roundtrips of delay, so that a sufficient volume of probe=20 > traffic can be sent to determine whether the path can support=20 > a subsequent flow. Also, it is unclear how the probe traffic=20 > is being prevented from negatively affecting regular flows.=20 > Without such mechanisms, what's the benefit over simply=20 > admitting the new flow? Etc. There are so many open questions=20 > around such a mechanism that I question whether the IETF is=20 > the right place for this discussion. As far as I'm aware=20 > there is no other Internet protocol that uses something=20 > similar to probing. >=20 > > The design of > > the PCN probing mechanism needs to be document in a stand alone =20 > > draft so > > that it can be used in a PCN solution when needed. >=20 > It's too early to discuss where probing should be described. >=20 > > This means that not > > every PCN domain needs to support probing but some PCN domains may > > choose to support probing because it solves specific configuration > > issues (ECMP, etc.) that are important to them. >=20 > The need for probing hasn't been sufficiently motivated. It remains =20 > unclear what the benefits are, and it it certainly isn't part of the =20 > PCN mechanisms that are outlined in the current charter. >=20 > > I believe that the probing issues needs to be address by=20 > the PCN group > > in a detailed proposal document in the draft and present to=20 > the group. > > Once we have a good understanding of the proposed probing solution =20 > > then > > we can pass judgment on complexity, security, and performance. >=20 > I disagree. The WG should discuss the simplest possible=20 > solution that =20 > will fullfil the chartered goals. >=20 > I can't stress enough that simplicity is key. It's perfectly OK if =20 > the initial PCN solution cannot support domains that use ECMP or =20 > don't have a lot of statistical multiplexing. As long as it offers =20 > sufficient benefit to some domains such that it will see deployment =20 > and use, it can always be extended later. (Heck, if PCN offers =20 > sufficient benefit, domains may end up turning off ECMP to run PCN.) >=20 > Finally, it's not only whether or not PCN needs probing. As I=20 > said in =20 > my last email, I'm worried that the WG generally seems to have =20 > settled on a mode of working where all the different proposals and =20 > ideas will be merged into one. The result is not likely to be a very =20 > simple solution. We have ample experience with solutions that have =20 > been designed in this manner failing to gain any traction, due to =20 > their complexities. >=20 > Merging all proposals into one is a feel-good approach that =20 > guarantees that there won't be any losers - all proposals live on in =20 > some form - but it doesn't guarantee that the merged outcome will be =20 > simple, usable and deployable. >=20 > As I've said before, I'd like to strongly encourage the WG to=20 > instead =20 > discuss which of the proposals is the best basis for a *simple* =20 > solution that will fulfill the chartered goals. We'd like the=20 > outcome =20 > of the first phase of work to be something that people will usefully =20 > deploy in some domains. Without demonstrated deployability and use, =20 > the need for continued future work on PCN is questionable. >=20 > Lars >=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Oct 03 14:33:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id91q-0001Ov-GS; Wed, 03 Oct 2007 14:33:02 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Id91p-0001Op-Cd for pcn-confirm+ok@megatron.ietf.org; Wed, 03 Oct 2007 14:33:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id91o-0001O9-Ty for pcn@ietf.org; Wed, 03 Oct 2007 14:33:01 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Id91Q-0002vE-Sy for pcn@ietf.org; Wed, 03 Oct 2007 14:32:38 -0400 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l93IWX700159; Wed, 3 Oct 2007 18:32:34 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PCN] FW: I-D ACTION:draft-babiarz-pcn-3sm-00.txt Date: Wed, 3 Oct 2007 14:32:10 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB646512754010@zcarhxm1.corp.nortel.com> In-Reply-To: <66C55C26FA491C42A9C9BB62A376DAFF05FEA8@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] FW: I-D ACTION:draft-babiarz-pcn-3sm-00.txt thread-index: Ace9iWWi634qt9N+RbasyEGXvJ9y5AAC1p1wEan/iSAAa5BRwA== References: <9671A92C3C8B5744BC97F855F7CB64651115D555@zcarhxm1.corp.nortel.com> <66C55C26FA491C42A9C9BB62A376DAFF05FEA8@E03MVB1-UKBR.domain1.systemhost.net> From: "Jozef Babiarz" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: a569a4168062bb63d79812a50c918a82 Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0035584534==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0035584534== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C805EB.B6A16AA5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C805EB.B6A16AA5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ben, Thanks for catching this error in the draft as very few people look at the appendix very carefully. I will try to go through RFC2697 section 3 below to make sure I understand the issue. Comments denoted by [PCN comment] are my explanations for threshold marking for admission control. Taken form RFC2697. 3. Metering The behavior of the Meter is specified in terms of its mode and two token buckets, C and E, which both share the common rate CIR. The maximum size of the token bucket C is CBS and the maximum size of the token bucket E is EBS. The token buckets C and E are initially (at time 0) full, i.e., the token count Tc(0) =3D CBS and the token count Te(0) =3D EBS. = Thereafter, the token counts Tc and Te are updated CIR times per second as follows: o If Tc is less than CBS, Tc is incremented by one, else o if Te is less then EBS, Te is incremented by one, else o neither Tc nor Te is incremented. When a packet of size B bytes arrives at time t, the following happens if the srTCM is configured to operate in the Color-Blind mode: o If Tc(t)-B >=3D 0, the packet is green and Tc is decremented by B down to the minimum value of 0, else [PCN Comment]When the above is true, packets are green (not AS-marked) [PCN Comment]When Tc(t)-B >=3D 0 is not true than the below statement is tested. o if Te(t)-B >=3D 0, the packets is yellow and Te is decremented by = B down to the minimum value of 0, else [PCN Comment]When the above is true, packets are marked yellow (AS-marked).=20 o the packet is red and neither Tc nor Te is decremented. [PCN Comment] Packet is AS-marked. I think I see the problem, when tokens are added to Tc and Te, the addition of tokens is to Tc first. This may cause the next packet to be green if the addition of tokens is greater than the size of next packet. This is not equivalent to the behavior for AR-Meter and AS-Marker in section 2.2.2. We will update the draft indicating that some changes to pseudo code of srTCM are required to produce equivalent behavior.=20 I think if we change the order at which we add tokens to the token bucket will fix the problem. If we add tokens to Te first that should produce similar behavior to section 2.2.2. o if Te is less than EBS, Te is incremented by one, else o If Tc is less than CBS, Tc is incremented by one, else o neither Tc nor Te is incremented. Let me know if you agree. Regards, Joe email:babiarz@nortel.com Telephone:613-763-6098 -----Original Message----- From: ben.strulo@bt.com [mailto:ben.strulo@bt.com]=20 Sent: October 1, 2007 11:17 AM To: Babiarz, Jozef (CAR:0S03); pcn@ietf.org Subject: RE: [PCN] FW: I-D ACTION:draft-babiarz-pcn-3sm-00.txt Hi Joe (All) Sorry about the late comments but my attention was recently drawn to this draft and in particular its approach to simulate threshold marking. Appendix A.6 suggests that a single rate three colour marker can be used to perform threshold marking. I think this is not true. If you configure the srTCM in the way suggested it will mark exactly the same packets as a single token bucket of length MBS doing tail marking. It is true that the fill level of the E bucket will correctly track the fill level of the larger token bucket (of length TB.size) that we are trying to emulate. However, the fill level of the E bucket does not affect the marking which will be done if and only if the C bucket is at its tail. Thus the setup becomes equivalent to the C bucket alone. HTH Ben Strulo > -----Original Message----- > From: Jozef Babiarz [mailto:babiarz@nortel.com]=20 > Sent: 03 July 2007 18:18 > To: pcn@ietf.org > Subject: [PCN] FW: I-D ACTION:draft-babiarz-pcn-3sm-00.txt >=20 >=20 > Hi all, > In an email below there is a link to 00 version of pcn-3sm=20 > draft that defines metering and marking for admission control=20 > and flow termination. We call it three state PCN marking=20 > because there are three conditions, packets are not marked,=20 > packets marked to indicate that admission of additional flows=20 > should be stopped and finally condition where flows are=20 > marked to indicate that termination is needed. This draft=20 > incorporates the metering and marking approach for flow=20 > termination that was defined in=20 > draft-babiarz-pcn-explicit-marking-00.=20 >=20 > Simulation results for the proposed "AR-metering and=20 > AS-re-marking" and "SR-metering and ET-re-marking" will be=20 > published in a separate draft. >=20 > Regards, Joe > email:babiarz@nortel.com > Telephone:613-763-6098 > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: July 3, 2007 11:15 AM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-babiarz-pcn-3sm-00.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. >=20 >=20 > Title : Three State PCN Marking > Author(s) : J. Babiarz, et al. > Filename : draft-babiarz-pcn-3sm-00.txt > Pages : 24 > Date : 2007-7-3 > =09 > This document proposes metering and marking mechanisms for PCN- > enabled nodes to label packets with pre-congestion=20 > information. The > marker marks all PCN packets with an admission-stop (AS)=20 > codepoint if > the PCN traffic rate on a link exceeds its admissible rate (AR) and > when it exceeds its supportable rate (SR), it marks some of those > packets exceeding SR with an excess-traffic (ET) codepoint. The > flows with ET-marked packets will be terminated until the aggregate > PCN traffic on the path decreases below its SR. This document > proposes metering and marking mechanisms for these objectives. >=20 >=20 > A URL for this Internet-Draft is:=20 > http://www.ietf.org/internet-drafts/draft-babiarz-pcn-3sm-00.txt >=20 > To remove yourself from the I-D Announcement list, send a message to=20 > i-d-announce-request@ietf.org with the word unsubscribe in=20 > the body of=20 > the message.=20 > You can also visit=20 > https://www1.ietf.org/mailman/listinfo/I-D-announce=20 > to change your subscription settings. >=20 > Internet-Drafts are also available by anonymous FTP. Login with the=20 > username "anonymous" and a password of your e-mail address. After=20 > logging in, type "cd internet-drafts" and then=20 > "get draft-babiarz-pcn-3sm-00.txt". >=20 > A list of Internet-Drafts directories can be found in=20 > http://www.ietf.org/shadow.html=20 > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-babiarz-pcn-3sm-00.txt". > =09 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant=20 > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. >=20 > Below is the data which will enable a MIME compliant mail=20 > reader implementation to automatically retrieve the ASCII=20 > version of the Internet-Draft. >=20 ------_=_NextPart_001_01C805EB.B6A16AA5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [PCN] FW: I-D ACTION:draft-babiarz-pcn-3sm-00.txt

Hi Ben,

Thanks for catching this error in the draft as very = few people look at the appendix very carefully.

I will try to go through RFC2697 section 3 below to = make sure I understand the issue. Comments denoted by [PCN comment] are = my explanations for threshold marking for admission = control.

Taken form RFC2697.

3. = Metering

   The behavior of the Meter is specified in terms of its = mode and two

   token buckets, C and E, which both share the common = rate CIR.  The

   maximum size of the token bucket C is CBS and the = maximum size of the

   token bucket E is = EBS.

   The token buckets C and E are initially (at time 0) = full, i.e., the

   token count Tc(0) =3D CBS and the token count Te(0) = =3D EBS.  Thereafter,

   the token counts Tc and Te are updated CIR times per = second as

   follows:

     o If Tc is less than CBS, Tc is = incremented by one, else

     o if Te is less then EBS, Te is = incremented by one, else

     o neither Tc nor Te is = incremented.

   When a packet of size B bytes arrives at time t, the = following

   happens if the srTCM is configured to operate in the = Color-Blind

   mode:

     o If Tc(t)-B >=3D 0, the packet is = green and Tc is decremented by B

       down to the minimum value of = 0, else

[PCN Comment]When the above is true, packets are = green (not AS-marked)

[PCN Comment]When Tc(t)-B >=3D 0 is not true = than the below statement is tested.

     o if Te(t)-B >=3D 0, the packets is = yellow and Te is decremented by B

       down to the minimum value of = 0, else

[PCN Comment]When the above is true, packets are = marked yellow (AS-marked).

     o the packet is red and neither Tc nor Te = is decremented.

[PCN Comment] Packet is = AS-marked.

I think I see the problem, when tokens are added to = Tc and Te, the addition of tokens is to Tc first. This may cause the = next packet to be green if the addition of tokens is greater than the = size of next packet. This is not equivalent to the behavior for AR-Meter = and AS-Marker in section 2.2.2. We will update the draft indicating that = some changes to pseudo code of srTCM = are required to produce equivalent behavior. =

I think if we change the order at which we add = tokens to the token bucket will fix the problem. If we add tokens to Te = first that should produce similar behavior to = section 2.2.2.

o if Te is less than EBS, Te is incremented by one, = else

o If Tc is less than CBS, Tc is incremented by one, = else

o neither Tc nor Te is = incremented.

Let me know if you agree.

Regards, Joe

email:babiarz@nortel.com

Telephone:613-763-6098

-----Original Message-----
From: ben.strulo@bt.com [mailto:ben.strulo@bt.com]
Sent: October 1, 2007 11:17 AM
To: Babiarz, Jozef (CAR:0S03); pcn@ietf.org
Subject: RE: [PCN] FW: I-D = ACTION:draft-babiarz-pcn-3sm-00.txt

Hi = Joe (All)

Sorry about the late comments but my attention was recently drawn = to

this draft and in particular its approach to simulate threshold = marking.

Appendix A.6 suggests that a single rate three colour marker can be = used

to = perform threshold marking.

I = think this is not true.

If = you configure the srTCM in the way suggested it will mark exactly = the

same packets as a single token bucket of length MBS doing tail = marking.

It = is true that the fill level of the E bucket will correctly track = the

fill level of the larger token bucket (of length TB.size) that we = are

trying to emulate.  However, the fill level of the E bucket = does not

affect the marking which will be done if and only if the C bucket = is at

its tail.  Thus the setup becomes equivalent to the C bucket = alone.

HTH

Ben Strulo

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

> From: Jozef Babiarz [mailto:babiarz@nortel.com] =

> Sent: 03 July 2007 18:18

> To: pcn@ietf.org

> Subject: [PCN] FW: I-D = ACTION:draft-babiarz-pcn-3sm-00.txt

>

>

> Hi all,

> In an email below there is a link to 00 version of pcn-3sm =

> draft that defines metering and marking for admission control =

> and flow termination. We call it three state PCN marking =

> because there are three conditions, packets are not marked, =

> packets marked to indicate that admission of additional flows =

> should be stopped and finally condition where flows are =

> marked to indicate that termination is needed. This draft =

> incorporates the metering and marking approach for flow =

> termination that was defined in

> draft-babiarz-pcn-explicit-marking-00.

>

> Simulation results for the proposed "AR-metering and =

> AS-re-marking" and "SR-metering and = ET-re-marking" will be

> published in a separate draft.

>

> Regards, Joe

> email:babiarz@nortel.com

> Telephone:613-763-6098

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

> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org<= /A>]

> Sent: July 3, 2007 11:15 AM

> To: i-d-announce@ietf.org

> Subject: I-D = ACTION:draft-babiarz-pcn-3sm-00.txt

>

> A New Internet-Draft is available from the on-line = Internet-Drafts

> directories.

>

>

>       Title   =         : Three State PCN = Marking

>       = Author(s)       : J. Babiarz, et = al.

>       = Filename        : = draft-babiarz-pcn-3sm-00.txt

>       Pages   =         : 24

>       Date    =         : 2007-7-3

>      

>    This document proposes metering and marking = mechanisms for PCN-

>    enabled nodes to label packets with = pre-congestion

> information.  The

>    marker marks all PCN packets with an = admission-stop (AS)

> codepoint if

>    the PCN traffic rate on a link exceeds its = admissible rate (AR) and

>    when it exceeds its supportable rate (SR), = it marks some of those

>    packets exceeding SR with an excess-traffic = (ET) codepoint.  The

>    flows with ET-marked packets will be = terminated until the aggregate

>    PCN traffic on the path decreases below its = SR.  This document

>    proposes metering and marking mechanisms for = these objectives.

>

>

> A URL for this Internet-Draft is:

> http://www.ietf.org/internet-drafts/draft-babiarz-pcn-3sm-00.txt

>

> To remove yourself from the I-D Announcement list, send a = message to

> i-d-announce-request@ietf.org with the word unsubscribe in =

> the body of

> the message.

> You can also visit

> https://www1= .ietf.org/mailman/listinfo/I-D-announce

> to change your subscription settings.

>

> Internet-Drafts are also available by anonymous FTP. Login = with the

> username "anonymous" and a password of your e-mail = address. After

> logging in, type "cd internet-drafts" and then =

> "get = draft-babiarz-pcn-3sm-00.txt".

>

> A list of Internet-Drafts directories can be found in =

> http://www.ietf.org/shadow.html<= /A>

> or ftp://ftp.ietf.org/iet= f/1shadow-sites.txt

>

> Internet-Drafts can also be obtained by = e-mail.

>

> Send a message to:

>       = mailserv@ietf.org.

> In the body type:

>       "FILE = /internet-drafts/draft-babiarz-pcn-3sm-00.txt".

>      

> NOTE: The mail server at ietf.org can return the document = in

>       MIME-encoded form by using the = "mpack" utility.  To use this

>       feature, insert the command = "ENCODING mime" before the "FILE"

>       command.  To decode the = response(s), you will need "munpack" or

>       a MIME-compliant mail = reader.  Different MIME-compliant

> mail readers

>       exhibit different behavior, = especially when dealing with

>       "multipart" MIME = messages (i.e. documents which have been split

>       up into multiple messages), so = check your local documentation on

>       how to manipulate these = messages.

>

> Below is the data which will enable a MIME compliant mail =

> reader implementation to automatically retrieve the ASCII =

> version of the Internet-Draft.

>

------_=_NextPart_001_01C805EB.B6A16AA5-- --===============0035584534== 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 --===============0035584534==-- From pcn-bounces@ietf.org Wed Oct 03 16:16:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdAdI-0000PW-7I; Wed, 03 Oct 2007 16:15:48 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IdAdH-0000PR-Mv for pcn-confirm+ok@megatron.ietf.org; Wed, 03 Oct 2007 16:15:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdAdH-0000PI-D3 for pcn@ietf.org; Wed, 03 Oct 2007 16:15:47 -0400 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 1IdAdA-000150-Ud for pcn@ietf.org; Wed, 03 Oct 2007 16:15:47 -0400 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 2D6F2BF40; Wed, 3 Oct 2007 22:15:35 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 1F768BF5C; Wed, 3 Oct 2007 22:15:35 +0200 (CEST) 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 B2189C507; Wed, 3 Oct 2007 22:15:31 +0200 (CEST) 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 l93KFVh01964; Wed, 3 Oct 2007 22:15:31 +0200 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 3D0356F591; Wed, 3 Oct 2007 22:08:34 +0200 (CEST) Message-ID: <4703F7B6.5020906@informatik.uni-wuerzburg.de> Date: Wed, 03 Oct 2007 22:12:38 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ben.strulo@bt.com Subject: Re: [PCN] FW: I-D ACTION:draft-babiarz-pcn-3sm-00.txt References: <66C55C26FA491C42A9C9BB62A376DAFF05FEA8@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <66C55C26FA491C42A9C9BB62A376DAFF05FEA8@E03MVB1-UKBR.domain1.systemhost.net> 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: d16ce744298aacf98517bc7c108bd198 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: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Ben, thanks for notifying us! You are right, there is a mistake in A.6 of http://www.ietf.org/internet-drafts/draft-babiarz-pcn-3sm-00.txt CBS = MBS is correct, but we need EBS = TB.size - MBS (instead of EBS = TB.size) Then it should work. Can you check that, please? Please let us know! Regards, Michael ben.strulo@bt.com wrote: > Hi Joe (All) > > Sorry about the late comments but my attention was recently drawn to > this draft and in particular its approach to simulate threshold marking. > > Appendix A.6 suggests that a single rate three colour marker can be used > to perform threshold marking. > > I think this is not true. > > If you configure the srTCM in the way suggested it will mark exactly the > same packets as a single token bucket of length MBS doing tail marking. > It is true that the fill level of the E bucket will correctly track the > fill level of the larger token bucket (of length TB.size) that we are > trying to emulate. However, the fill level of the E bucket does not > affect the marking which will be done if and only if the C bucket is at > its tail. Thus the setup becomes equivalent to the C bucket alone. > > HTH > > Ben Strulo > > >> -----Original Message----- >> From: Jozef Babiarz [mailto:babiarz@nortel.com] >> Sent: 03 July 2007 18:18 >> To: pcn@ietf.org >> Subject: [PCN] FW: I-D ACTION:draft-babiarz-pcn-3sm-00.txt >> >> >> Hi all, >> In an email below there is a link to 00 version of pcn-3sm >> draft that defines metering and marking for admission control >> and flow termination. We call it three state PCN marking >> because there are three conditions, packets are not marked, >> packets marked to indicate that admission of additional flows >> should be stopped and finally condition where flows are >> marked to indicate that termination is needed. This draft >> incorporates the metering and marking approach for flow >> termination that was defined in >> draft-babiarz-pcn-explicit-marking-00. >> >> Simulation results for the proposed "AR-metering and >> AS-re-marking" and "SR-metering and ET-re-marking" will be >> published in a separate draft. >> >> Regards, Joe >> email:babiarz@nortel.com >> Telephone:613-763-6098 >> -----Original Message----- >> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >> Sent: July 3, 2007 11:15 AM >> To: i-d-announce@ietf.org >> Subject: I-D ACTION:draft-babiarz-pcn-3sm-00.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Three State PCN Marking >> Author(s) : J. Babiarz, et al. >> Filename : draft-babiarz-pcn-3sm-00.txt >> Pages : 24 >> Date : 2007-7-3 >> >> This document proposes metering and marking mechanisms for PCN- >> enabled nodes to label packets with pre-congestion >> information. The >> marker marks all PCN packets with an admission-stop (AS) >> codepoint if >> the PCN traffic rate on a link exceeds its admissible rate (AR) and >> when it exceeds its supportable rate (SR), it marks some of those >> packets exceeding SR with an excess-traffic (ET) codepoint. The >> flows with ET-marked packets will be terminated until the aggregate >> PCN traffic on the path decreases below its SR. This document >> proposes metering and marking mechanisms for these objectives. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-babiarz-pcn-3sm-00.txt >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request@ietf.org with the word unsubscribe in >> the body of >> the message. >> You can also visit >> https://www1.ietf.org/mailman/listinfo/I-D-announce >> to change your subscription settings. >> >> Internet-Drafts are also available by anonymous FTP. Login with the >> username "anonymous" and a password of your e-mail address. After >> logging in, type "cd internet-drafts" and then >> "get draft-babiarz-pcn-3sm-00.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE /internet-drafts/draft-babiarz-pcn-3sm-00.txt". >> >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant >> mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> Below is the data which will enable a MIME compliant mail >> reader implementation to automatically retrieve the ASCII >> version of the Internet-Draft. >> >> > > > _______________________________________________ > 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 Thu Oct 04 04:43:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdMIC-00045U-8c; Thu, 04 Oct 2007 04:42:48 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IdMIA-00044S-SP for pcn-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 04:42:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdMIA-000414-Hd for pcn@ietf.org; Thu, 04 Oct 2007 04:42:46 -0400 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdMI2-0006At-6N for pcn@ietf.org; Thu, 04 Oct 2007 04:42:44 -0400 Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Oct 2007 09:42:22 +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] FW: I-D ACTION:draft-babiarz-pcn-3sm-00.txt Date: Thu, 4 Oct 2007 09:42:21 +0100 Message-ID: <66C55C26FA491C42A9C9BB62A376DAFF05FEB0@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <4703F7B6.5020906@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] FW: I-D ACTION:draft-babiarz-pcn-3sm-00.txt Thread-Index: AcgF+iiLL3Xc68I5QJaVVb5ka2uz1QAZ+htQ From: To: X-OriginalArrivalTime: 04 Oct 2007 08:42:22.0115 (UTC) FILETIME=[7B0E3730:01C80662] X-Spam-Score: -1.0 (-) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Michael No that doesn't work either. The gist is that the C bucket controls the marking on its own and changing the E bucket has no effect on the C bucket. Just think about the way the C bucket goes up and down and you can see that the level in the E bucket has no effect on it. The E bucket does control whether the colouring is yellow or red. But that does not change the marking. Ben > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de]=20 > Sent: 03 October 2007 21:13 > To: Strulo,B,Ben,CXR9 R > Cc: babiarz@nortel.com; pcn@ietf.org; Xiao-Gao (Leo) Liu > Subject: Re: [PCN] FW: I-D ACTION:draft-babiarz-pcn-3sm-00.txt >=20 >=20 > Hi Ben, >=20 > thanks for notifying us! You are right, there is a mistake in=20 > A.6 of=20 > http://www.ietf.org/internet-drafts/draft-babiarz-pcn-3sm-00.txt >=20 > CBS =3D MBS is correct, but we need > EBS =3D TB.size - MBS (instead of EBS =3D TB.size) >=20 > Then it should work. Can you check that, please? Please let us know! >=20 > Regards, >=20 > Michael >=20 >=20 > ben.strulo@bt.com wrote: > > Hi Joe (All) > > > > Sorry about the late comments but my attention was recently=20 > drawn to=20 > > this draft and in particular its approach to simulate threshold=20 > > marking. > > > > Appendix A.6 suggests that a single rate three colour marker can be=20 > > used to perform threshold marking. > > > > I think this is not true. > > > > If you configure the srTCM in the way suggested it will=20 > mark exactly=20 > > the same packets as a single token bucket of length MBS doing tail=20 > > marking. It is true that the fill level of the E bucket=20 > will correctly=20 > > track the fill level of the larger token bucket (of length TB.size)=20 > > that we are trying to emulate. However, the fill level of the E=20 > > bucket does not affect the marking which will be done if=20 > and only if=20 > > the C bucket is at its tail. Thus the setup becomes=20 > equivalent to the=20 > > C bucket alone. > > > > HTH > > > > Ben Strulo > > > > =20 > >> -----Original Message----- > >> From: Jozef Babiarz [mailto:babiarz@nortel.com] > >> Sent: 03 July 2007 18:18 > >> To: pcn@ietf.org > >> Subject: [PCN] FW: I-D ACTION:draft-babiarz-pcn-3sm-00.txt > >> > >> > >> Hi all, > >> In an email below there is a link to 00 version of pcn-3sm > >> draft that defines metering and marking for admission control=20 > >> and flow termination. We call it three state PCN marking=20 > >> because there are three conditions, packets are not marked,=20 > >> packets marked to indicate that admission of additional flows=20 > >> should be stopped and finally condition where flows are=20 > >> marked to indicate that termination is needed. This draft=20 > >> incorporates the metering and marking approach for flow=20 > >> termination that was defined in=20 > >> draft-babiarz-pcn-explicit-marking-00.=20 > >> > >> Simulation results for the proposed "AR-metering and > >> AS-re-marking" and "SR-metering and ET-re-marking" will be=20 > >> published in a separate draft. > >> > >> Regards, Joe > >> email:babiarz@nortel.com > >> Telephone:613-763-6098 > >> -----Original Message----- > >> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > >> Sent: July 3, 2007 11:15 AM > >> To: i-d-announce@ietf.org > >> Subject: I-D ACTION:draft-babiarz-pcn-3sm-00.txt > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. > >> > >> > >> Title : Three State PCN Marking > >> Author(s) : J. Babiarz, et al. > >> Filename : draft-babiarz-pcn-3sm-00.txt > >> Pages : 24 > >> Date : 2007-7-3 > >> =09 > >> This document proposes metering and marking mechanisms for PCN- > >> enabled nodes to label packets with pre-congestion > >> information. The > >> marker marks all PCN packets with an admission-stop (AS)=20 > >> codepoint if > >> the PCN traffic rate on a link exceeds its admissible=20 > rate (AR) and > >> when it exceeds its supportable rate (SR), it marks=20 > some of those > >> packets exceeding SR with an excess-traffic (ET) codepoint. The > >> flows with ET-marked packets will be terminated until=20 > the aggregate > >> PCN traffic on the path decreases below its SR. This document > >> proposes metering and marking mechanisms for these objectives. > >> > >> > >> A URL for this Internet-Draft is: > >> http://www.ietf.org/internet-drafts/draft-babiarz-pcn-3sm-00.txt > >> > >> To remove yourself from the I-D Announcement list, send a=20 > message to > >> i-d-announce-request@ietf.org with the word unsubscribe in=20 > >> the body of=20 > >> the message.=20 > >> You can also visit=20 > >> https://www1.ietf.org/mailman/listinfo/I-D-announce=20 > >> to change your subscription settings. > >> > >> Internet-Drafts are also available by anonymous FTP. Login with the > >> username "anonymous" and a password of your e-mail address. After=20 > >> logging in, type "cd internet-drafts" and then=20 > >> "get draft-babiarz-pcn-3sm-00.txt". > >> > >> A list of Internet-Drafts directories can be found in > >> http://www.ietf.org/shadow.html=20 > >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >> > >> Internet-Drafts can also be obtained by e-mail. > >> > >> Send a message to: > >> mailserv@ietf.org. > >> In the body type: > >> "FILE /internet-drafts/draft-babiarz-pcn-3sm-00.txt". > >> =09 > >> NOTE: The mail server at ietf.org can return the document in > >> MIME-encoded form by using the "mpack" utility. To use this > >> feature, insert the command "ENCODING mime" before the "FILE" > >> command. To decode the response(s), you will need "munpack" or > >> a MIME-compliant mail reader. Different MIME-compliant > >> mail readers > >> exhibit different behavior, especially when dealing with > >> "multipart" MIME messages (i.e. documents which have been split > >> up into multiple messages), so check your local documentation on > >> how to manipulate these messages. > >> > >> Below is the data which will enable a MIME compliant mail > >> reader implementation to automatically retrieve the ASCII=20 > >> version of the Internet-Draft. > >> > >> =20 > > > > > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www1.ietf.org/mailman/listinfo/pcn > > =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=20 > mailto:menth@informatik.uni-wuerzburg.de > http://www3.informatik.uni-wuerzburg.de/research/ngn >=20 >=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Oct 04 13:43:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdUjH-0005f6-2b; Thu, 04 Oct 2007 13:43:19 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IdUjF-0005f0-7n for pcn-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 13:43:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdUjE-0005er-Rb for pcn@ietf.org; Thu, 04 Oct 2007 13:43:16 -0400 Received: from wrzx28.rz.uni-wuerzburg.de ([132.187.3.28] helo=mailrelay.rz.uni-wuerzburg.de) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdUjD-0007pW-Kn for pcn@ietf.org; Thu, 04 Oct 2007 13:43:16 -0400 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 93E58AF93; Thu, 4 Oct 2007 19:43:14 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 86448B182; Thu, 4 Oct 2007 19:43:14 +0200 (CEST) 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 CD0D7AF93; Thu, 4 Oct 2007 19:43:09 +0200 (CEST) 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 l94Hh9h11474; Thu, 4 Oct 2007 19:43:09 +0200 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 56F3B6F591; Thu, 4 Oct 2007 19:36:11 +0200 (CEST) Message-ID: <47052581.7020007@informatik.uni-wuerzburg.de> Date: Thu, 04 Oct 2007 19:40:17 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ben.strulo@bt.com Subject: Re: [PCN] FW: I-D ACTION:draft-babiarz-pcn-3sm-00.txt References: <66C55C26FA491C42A9C9BB62A376DAFF05FEB0@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <66C55C26FA491C42A9C9BB62A376DAFF05FEB0@E03MVB1-UKBR.domain1.systemhost.net> 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: 453b1bfcf0292bffe4cab90ba115f503 Cc: pcn@ietf.org, Frank Lehrieder X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Ben, we can view the two token buckets of RFC 2697 as a decomposition of one large token bucket when we put the token bucket C on top of token bucket E: + C.full, VQ.empty | | token bucket C, rate: CIR, size CBS: marking: green=no admission-stop | + C.empty, E.full, VQ.markingThreshold | | | token bucket E, rate: CIR, size EBS: marking: yellow=admission-stop | | + E.empty, VQ.full Look at the corresponding virtual queue (turn the whole thing upside down): VQ.rate=CIR VQ.size=EBS+CBS VQ.markingThreshold=CBS I hope that this equivalence is right and obvious. Do you agree or is there a mistake I have overlooked? This is what we wanted to express in the 3sm draft. BTW, the descriptive text in A.6 is wrong, but it is consistent with the flaw we detected yesterday: > If it is conform to (CIR, EBS), it is colored yellow. > => > If it is conform to (CIR, EBS+CBS), it is colored yellow. > ^^^^ > But what's the impact of EBS on the marking behavior? The size of EBS (or VQ.size-VQ.markingThreshold) controls the marking behavior in overload situations. Consider the long-term PCN rate is larger than CIR, but due to short-time fluctuations it is smaller than CIR for a while. If EBS is small, Te (fill state of token bucket E) increases, E fills up, and the algorithm stops marking. If EBS is large, it takes longer until short-time fluctuations stop the marking. We almost finished a study giving insight into the impact of the parameters on the marking behavior in different scenarios. We'll send it to the list when it's done. Regards, Michael ben.strulo@bt.com wrote: > Hi Michael > > No that doesn't work either. > > The gist is that the C bucket controls the marking on its own and > changing the E bucket has no effect on the C bucket. Just think about > the way the C bucket goes up and down and you can see that the level in > the E bucket has no effect on it. > > The E bucket does control whether the colouring is yellow or red. But > that does not change the marking. > > Ben > > >> -----Original Message----- >> From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] >> Sent: 03 October 2007 21:13 >> To: Strulo,B,Ben,CXR9 R >> Cc: babiarz@nortel.com; pcn@ietf.org; Xiao-Gao (Leo) Liu >> Subject: Re: [PCN] FW: I-D ACTION:draft-babiarz-pcn-3sm-00.txt >> >> >> Hi Ben, >> >> thanks for notifying us! You are right, there is a mistake in >> A.6 of >> http://www.ietf.org/internet-drafts/draft-babiarz-pcn-3sm-00.txt >> >> CBS = MBS is correct, but we need >> EBS = TB.size - MBS (instead of EBS = TB.size) >> >> Then it should work. Can you check that, please? Please let us know! >> >> Regards, >> >> Michael >> >> >> ben.strulo@bt.com wrote: >> >>> Hi Joe (All) >>> >>> Sorry about the late comments but my attention was recently >>> >> drawn to >> >>> this draft and in particular its approach to simulate threshold >>> marking. >>> >>> Appendix A.6 suggests that a single rate three colour marker can be >>> used to perform threshold marking. >>> >>> I think this is not true. >>> >>> If you configure the srTCM in the way suggested it will >>> >> mark exactly >> >>> the same packets as a single token bucket of length MBS doing tail >>> marking. It is true that the fill level of the E bucket >>> >> will correctly >> >>> track the fill level of the larger token bucket (of length TB.size) >>> that we are trying to emulate. However, the fill level of the E >>> bucket does not affect the marking which will be done if >>> >> and only if >> >>> the C bucket is at its tail. Thus the setup becomes >>> >> equivalent to the >> >>> C bucket alone. >>> >>> HTH >>> >>> Ben Strulo >>> >>> >>> >>>> -----Original Message----- >>>> From: Jozef Babiarz [mailto:babiarz@nortel.com] >>>> Sent: 03 July 2007 18:18 >>>> To: pcn@ietf.org >>>> Subject: [PCN] FW: I-D ACTION:draft-babiarz-pcn-3sm-00.txt >>>> >>>> >>>> Hi all, >>>> In an email below there is a link to 00 version of pcn-3sm >>>> draft that defines metering and marking for admission control >>>> and flow termination. We call it three state PCN marking >>>> because there are three conditions, packets are not marked, >>>> packets marked to indicate that admission of additional flows >>>> should be stopped and finally condition where flows are >>>> marked to indicate that termination is needed. This draft >>>> incorporates the metering and marking approach for flow >>>> termination that was defined in >>>> draft-babiarz-pcn-explicit-marking-00. >>>> >>>> Simulation results for the proposed "AR-metering and >>>> AS-re-marking" and "SR-metering and ET-re-marking" will be >>>> published in a separate draft. >>>> >>>> Regards, Joe >>>> email:babiarz@nortel.com >>>> Telephone:613-763-6098 >>>> -----Original Message----- >>>> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >>>> Sent: July 3, 2007 11:15 AM >>>> To: i-d-announce@ietf.org >>>> Subject: I-D ACTION:draft-babiarz-pcn-3sm-00.txt >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> >>>> >>>> Title : Three State PCN Marking >>>> Author(s) : J. Babiarz, et al. >>>> Filename : draft-babiarz-pcn-3sm-00.txt >>>> Pages : 24 >>>> Date : 2007-7-3 >>>> >>>> This document proposes metering and marking mechanisms for PCN- >>>> enabled nodes to label packets with pre-congestion >>>> information. The >>>> marker marks all PCN packets with an admission-stop (AS) >>>> codepoint if >>>> the PCN traffic rate on a link exceeds its admissible >>>> >> rate (AR) and >> >>>> when it exceeds its supportable rate (SR), it marks >>>> >> some of those >> >>>> packets exceeding SR with an excess-traffic (ET) codepoint. The >>>> flows with ET-marked packets will be terminated until >>>> >> the aggregate >> >>>> PCN traffic on the path decreases below its SR. This document >>>> proposes metering and marking mechanisms for these objectives. >>>> >>>> >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-babiarz-pcn-3sm-00.txt >>>> >>>> To remove yourself from the I-D Announcement list, send a >>>> >> message to >> >>>> i-d-announce-request@ietf.org with the word unsubscribe in >>>> the body of >>>> the message. >>>> You can also visit >>>> https://www1.ietf.org/mailman/listinfo/I-D-announce >>>> to change your subscription settings. >>>> >>>> Internet-Drafts are also available by anonymous FTP. Login with the >>>> username "anonymous" and a password of your e-mail address. After >>>> logging in, type "cd internet-drafts" and then >>>> "get draft-babiarz-pcn-3sm-00.txt". >>>> >>>> A list of Internet-Drafts directories can be found in >>>> http://www.ietf.org/shadow.html >>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>> >>>> Internet-Drafts can also be obtained by e-mail. >>>> >>>> Send a message to: >>>> mailserv@ietf.org. >>>> In the body type: >>>> "FILE /internet-drafts/draft-babiarz-pcn-3sm-00.txt". >>>> >>>> NOTE: The mail server at ietf.org can return the document in >>>> MIME-encoded form by using the "mpack" utility. To use this >>>> feature, insert the command "ENCODING mime" before the "FILE" >>>> command. To decode the response(s), you will need "munpack" or >>>> a MIME-compliant mail reader. Different MIME-compliant >>>> mail readers >>>> exhibit different behavior, especially when dealing with >>>> "multipart" MIME messages (i.e. documents which have been split >>>> up into multiple messages), so check your local documentation on >>>> how to manipulate these messages. >>>> >>>> Below is the data which will enable a MIME compliant mail >>>> reader implementation to automatically retrieve the ASCII >>>> version of the Internet-Draft. >>>> >>>> >>>> >>> _______________________________________________ >>> 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 > -- 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 Oct 04 17:31:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdYHr-0006Pi-Mg; Thu, 04 Oct 2007 17:31:15 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IdYHr-0006Pa-0W for pcn-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 17:31:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdYHq-0006PR-KB for pcn@ietf.org; Thu, 04 Oct 2007 17:31:14 -0400 Received: from wrzx28.rz.uni-wuerzburg.de ([132.187.3.28] helo=mailrelay.rz.uni-wuerzburg.de) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdYHp-0000QZ-AE for pcn@ietf.org; Thu, 04 Oct 2007 17:31:14 -0400 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 82E67AF2E; Thu, 4 Oct 2007 23:31:12 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 753E1B1C5; Thu, 4 Oct 2007 23:31:12 +0200 (CEST) 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 22BBCAF2E; Thu, 4 Oct 2007 23:31:10 +0200 (CEST) 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 l94LVAh12747; Thu, 4 Oct 2007 23:31:10 +0200 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id AB0EE6F591; Thu, 4 Oct 2007 23:24:11 +0200 (CEST) Message-ID: <47055AF1.5090503@informatik.uni-wuerzburg.de> Date: Thu, 04 Oct 2007 23:28:17 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ben.strulo@bt.com Subject: Re: [PCN] FW: I-D ACTION:draft-babiarz-pcn-3sm-00.txt References: <66C55C26FA491C42A9C9BB62A376DAFF05FEB0@E03MVB1-UKBR.domain1.systemhost.net> <47052581.7020007@informatik.uni-wuerzburg.de> In-Reply-To: <47052581.7020007@informatik.uni-wuerzburg.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: 8d89ee9312a95de8ee48d1c94511f1bb Cc: pcn@ietf.org, Frank Lehrieder X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Ben, after a short discussion with Joe: srTCM in RFC 2697 is not able to approximate threshold marking and the arguments provided in his last emails are absolutely correct. srTCM first refills token bucket C and if this is full it continues to refill E. I falsely thought that first token bucket E is refilled and then C. This is not the case, but necessary for our approximation of threshold marking by srTCM. We will correct this bug in 3sm. Thanks for reading and for pointing us to this fault! Regards, Michael Michael Menth wrote: > Hi Ben, > > we can view the two token buckets of RFC 2697 as a decomposition of > one large token bucket when we put the token bucket C on top of token > bucket E: > > + C.full, VQ.empty > | > | token bucket C, rate: CIR, size CBS: marking: green=no admission-stop > | > + C.empty, E.full, VQ.markingThreshold > | > | > | token bucket E, rate: CIR, size EBS: marking: yellow=admission-stop > | > | > + E.empty, VQ.full > > Look at the corresponding virtual queue (turn the whole thing upside > down): > VQ.rate=CIR > VQ.size=EBS+CBS > VQ.markingThreshold=CBS > > I hope that this equivalence is right and obvious. Do you agree or is > there a mistake I have overlooked? This is what we wanted to express > in the 3sm draft. > > BTW, the descriptive text in A.6 is wrong, but it is consistent with > the flaw we detected yesterday: > >> If it is conform to (CIR, EBS), it is colored yellow. >> > => > >> If it is conform to (CIR, EBS+CBS), it is colored yellow. >> ^^^^ >> > > But what's the impact of EBS on the marking behavior? The size of EBS > (or VQ.size-VQ.markingThreshold) controls the marking behavior in > overload situations. Consider the long-term PCN rate is larger than > CIR, but due to short-time fluctuations it is smaller than CIR for a > while. If EBS is small, Te (fill state of token bucket E) increases, E > fills up, and the algorithm stops marking. If EBS is large, it takes > longer until short-time fluctuations stop the marking. We almost > finished a study giving insight into the impact of the parameters on > the marking behavior in different scenarios. We'll send it to the list > when it's done. > > Regards, > > Michael > > > ben.strulo@bt.com wrote: >> Hi Michael >> >> No that doesn't work either. >> >> The gist is that the C bucket controls the marking on its own and >> changing the E bucket has no effect on the C bucket. Just think about >> the way the C bucket goes up and down and you can see that the level in >> the E bucket has no effect on it. >> >> The E bucket does control whether the colouring is yellow or red. But >> that does not change the marking. >> >> Ben >> >> >>> -----Original Message----- >>> From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] Sent: >>> 03 October 2007 21:13 >>> To: Strulo,B,Ben,CXR9 R >>> Cc: babiarz@nortel.com; pcn@ietf.org; Xiao-Gao (Leo) Liu >>> Subject: Re: [PCN] FW: I-D ACTION:draft-babiarz-pcn-3sm-00.txt >>> >>> >>> Hi Ben, >>> >>> thanks for notifying us! You are right, there is a mistake in A.6 of >>> http://www.ietf.org/internet-drafts/draft-babiarz-pcn-3sm-00.txt >>> >>> CBS = MBS is correct, but we need >>> EBS = TB.size - MBS (instead of EBS = TB.size) >>> >>> Then it should work. Can you check that, please? Please let us know! >>> >>> Regards, >>> >>> Michael >>> >>> >>> ben.strulo@bt.com wrote: >>> >>>> Hi Joe (All) >>>> >>>> Sorry about the late comments but my attention was recently >>> drawn to >>>> this draft and in particular its approach to simulate threshold >>>> marking. >>>> >>>> Appendix A.6 suggests that a single rate three colour marker can be >>>> used to perform threshold marking. >>>> >>>> I think this is not true. >>>> >>>> If you configure the srTCM in the way suggested it will >>> mark exactly >>>> the same packets as a single token bucket of length MBS doing tail >>>> marking. It is true that the fill level of the E bucket >>> will correctly >>>> track the fill level of the larger token bucket (of length TB.size) >>>> that we are trying to emulate. However, the fill level of the E >>>> bucket does not affect the marking which will be done if >>> and only if >>>> the C bucket is at its tail. Thus the setup becomes >>> equivalent to the >>>> C bucket alone. >>>> >>>> HTH >>>> >>>> Ben Strulo >>>> >>>> >>>>> -----Original Message----- >>>>> From: Jozef Babiarz [mailto:babiarz@nortel.com] >>>>> Sent: 03 July 2007 18:18 >>>>> To: pcn@ietf.org >>>>> Subject: [PCN] FW: I-D ACTION:draft-babiarz-pcn-3sm-00.txt >>>>> >>>>> >>>>> Hi all, >>>>> In an email below there is a link to 00 version of pcn-3sm >>>>> draft that defines metering and marking for admission control and >>>>> flow termination. We call it three state PCN marking because there >>>>> are three conditions, packets are not marked, packets marked to >>>>> indicate that admission of additional flows should be stopped and >>>>> finally condition where flows are marked to indicate that >>>>> termination is needed. This draft incorporates the metering and >>>>> marking approach for flow termination that was defined in >>>>> draft-babiarz-pcn-explicit-marking-00. >>>>> Simulation results for the proposed "AR-metering and >>>>> AS-re-marking" and "SR-metering and ET-re-marking" will be >>>>> published in a separate draft. >>>>> >>>>> Regards, Joe >>>>> email:babiarz@nortel.com >>>>> Telephone:613-763-6098 >>>>> -----Original Message----- >>>>> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >>>>> Sent: July 3, 2007 11:15 AM >>>>> To: i-d-announce@ietf.org >>>>> Subject: I-D ACTION:draft-babiarz-pcn-3sm-00.txt >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> directories. >>>>> >>>>> >>>>> Title : Three State PCN Marking >>>>> Author(s) : J. Babiarz, et al. >>>>> Filename : draft-babiarz-pcn-3sm-00.txt >>>>> Pages : 24 >>>>> Date : 2007-7-3 >>>>> >>>>> This document proposes metering and marking mechanisms for PCN- >>>>> enabled nodes to label packets with pre-congestion >>>>> information. The >>>>> marker marks all PCN packets with an admission-stop (AS) >>>>> codepoint if >>>>> the PCN traffic rate on a link exceeds its admissible >>> rate (AR) and >>> >>>>> when it exceeds its supportable rate (SR), it marks >>> some of those >>> >>>>> packets exceeding SR with an excess-traffic (ET) codepoint. The >>>>> flows with ET-marked packets will be terminated until >>> the aggregate >>> >>>>> PCN traffic on the path decreases below its SR. This document >>>>> proposes metering and marking mechanisms for these objectives. >>>>> >>>>> >>>>> A URL for this Internet-Draft is: >>>>> http://www.ietf.org/internet-drafts/draft-babiarz-pcn-3sm-00.txt >>>>> >>>>> To remove yourself from the I-D Announcement list, send a >>> message to >>> >>>>> i-d-announce-request@ietf.org with the word unsubscribe in the >>>>> body of the message. You can also visit >>>>> https://www1.ietf.org/mailman/listinfo/I-D-announce to change your >>>>> subscription settings. >>>>> >>>>> Internet-Drafts are also available by anonymous FTP. Login with the >>>>> username "anonymous" and a password of your e-mail address. After >>>>> logging in, type "cd internet-drafts" and then "get >>>>> draft-babiarz-pcn-3sm-00.txt". >>>>> >>>>> A list of Internet-Drafts directories can be found in >>>>> http://www.ietf.org/shadow.html or >>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>> >>>>> Internet-Drafts can also be obtained by e-mail. >>>>> >>>>> Send a message to: >>>>> mailserv@ietf.org. >>>>> In the body type: >>>>> "FILE /internet-drafts/draft-babiarz-pcn-3sm-00.txt". >>>>> >>>>> NOTE: The mail server at ietf.org can return the document in >>>>> MIME-encoded form by using the "mpack" utility. To use this >>>>> feature, insert the command "ENCODING mime" before the "FILE" >>>>> command. To decode the response(s), you will need "munpack" or >>>>> a MIME-compliant mail reader. Different MIME-compliant >>>>> mail readers >>>>> exhibit different behavior, especially when dealing with >>>>> "multipart" MIME messages (i.e. documents which have been split >>>>> up into multiple messages), so check your local documentation on >>>>> how to manipulate these messages. >>>>> >>>>> Below is the data which will enable a MIME compliant mail >>>>> reader implementation to automatically retrieve the ASCII version >>>>> of the Internet-Draft. >>>>> >>>>> >>>> _______________________________________________ >>>> 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 >> > -- 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 Sun Oct 07 15:40:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iebyl-0001lH-UW; Sun, 07 Oct 2007 15:39:55 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Iebyk-0001ky-5d for pcn-confirm+ok@megatron.ietf.org; Sun, 07 Oct 2007 15:39:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iebyj-0001kc-H1 for pcn@ietf.org; Sun, 07 Oct 2007 15:39:53 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iebyi-00023m-K6 for pcn@ietf.org; Sun, 07 Oct 2007 15:39:53 -0400 X-IronPort-AV: E=Sophos;i="4.21,240,1188792000"; d="scan'208";a="73315636" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 07 Oct 2007 15:39:52 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l97Jdpnd025626; Sun, 7 Oct 2007 15:39:51 -0400 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 l97Jdics011410; Sun, 7 Oct 2007 19:39:51 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 7 Oct 2007 15:39:44 -0400 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 Date: Sun, 7 Oct 2007 15:39:43 -0400 Message-ID: In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC4E4@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Questions on LC-PCN draft version 01 Thread-Index: AcfxoTfiMvYaDfTgQ9adZz5poNI4WwCxk0OgAGsQTGAEvbcRwA== From: "Anna Charny (acharny)" To: , "Georgios Karagiannis" , "Lars Westberg (KI/EAB)" X-OriginalArrivalTime: 07 Oct 2007 19:39:44.0777 (UTC) FILETIME=[CFF40F90:01C80919] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15466.000 X-TM-AS-Result: No--24.884200-8.000000-2 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7463; t=1191785991; x=1192649991; 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:=20Questions=20on=20=20LC-PCN=20draft=20version=2001 |Sender:=20 |To:=20, =0A=20=20=20=20=20=20=20=20=22Georg ios=20Karagiannis=22=20, =0A=20=20=20=20=20=20=20=2 0=22Lars=20Westberg=20(KI/EAB)=22=20; bh=IvFOx8gx5glSxCuFt/3s6SU2Ld2/ulqIRRgqpp8mIgE=; b=NKxHuxQJPtttLQ1sDtu/6FSgunUxAc7+913iN2AJE+rKPYlQ4bqKwM56L7xo3n8rvEvq8r2E +IMAlQWMYWTufTR1XOjKdSVS2tNgWd2tJOaHVqKAp3PpAhyuDQO2iGTp; 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: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: pcn@ietf.org Subject: [PCN] Questions on LC-PCN draft version 01 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Dear authors of the LC-PCN draft, Am I right that there has been no response yet to Phil's questions (attached at the end) on the new version of your draft below (I checked the pcn list and it does not seem it went there)? If the response was sent, can you resend it please? I have many of the same questions, and also a few additional ones. Here are some of them. 1) I do not understand whether pcn-lower_rate_egress and pcn_upper_rate ingress are expressed as a fraction of the total rate (a unitless entity, analogous to CLE) or an absolute value (in bits or bytes per second). The text seems to be contradictory on this point: =20 on page 8 it is a fraction: =20 "PCN_lower_rate_egress =3D predefined percentage of received = PCN_marking", while on page 13 it is an absolute rate: "If the incoming_PCN_marking_rate is higher than a preconfigured PCN_lower_rate_egress, ..." where the=20 (Incoming_PCN_marking_rate is clearly defined as abslolue rate on page 12: "Where the "incoming_PCN_marking_rate" is calculated as follows: incoming_PCN_marking_rate =3D (received number of "PCN_marking" DSCP during T)* N)/T;) 2) Regarding the question above,=20 * if pcn_lower_rate_eggress (and pcn_uppre-rate_egress) are absolute rates, then how do you choose that abslolute rate value, given that the rates of ingress-egress aggregates at the same ingress may be vastly different in magnitude? *if, however, pcn_lower_rate_eggress (and pcn_uppre-rate_egress) are ratios, then what is the guidance of setting these ratios so that the egress can always tell admission state from the termination state, given that the same marking is used for admission and termination marking? Specifically, suppose at the bottleneck pcn_lower_threshold is set to X, and pcn_upper_threshold to aX with some a>1 (assume for example = a=3D1.5). How does the egress node tell between the conditions when the total pcn traffic on the bottleneck is 1.1X (which is the state wnen admission is needed but termination is not, - in this case (1.1X-X)/X=3D0.1 traffic = is pcn-marked), and the case when the total traffic on the bottleneck is 1.1aX, which is the case when termination is needed, and (1.1ax-ax)/ax=3D0.1), if in both cases the ratio between marked and = total traffic is the same value 0.1? 3) On page 9, multicongestion error error is introduced, but the text is silent on how this error is defined and what is it set to (if it is a configuration parameter), or how it is measured (if it is something that is being measured). Can you explain, please? I have some more questions, including sharing those asked by Phil in the attached message), but I will stop now, as I hope clarifications on the above (and Phil's) questions will help understand the draft better... Thank you in advance for clarifying all this. Anna=20 > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 > Sent: Thursday, September 13, 2007 11:27 AM > To: anurag.bhargava@ericsson.com; pcn@ietf.org > Subject: RE: [PCN] LC-PCN version 01 uploaded >=20 > Anurag >=20 > Thanks for the revised draft, I can understand it much=20 > better. Here are some questions /misunderstandings. >=20 > Let me summarise to make sure I understand it right. >=20 > - two encodings are used. one ('PCN-marking') is used for=20 > both adm ctrl & termination to indicate the excess traffic.=20 > If a PCN-interior-node is PCN-marking some pkts, then it=20 > marks all other pkts with another encoding ('affected marking') >=20 > - the 'PCN-marking' algorithm has several regimes: > * when traffic rate is below PCN-lower-rate, no pkts are marked > * as the traffic rate climbs above the PCN-lower-rate, an=20 > increasing number of pkts are marked (marking rate =3D excess=20 > rate divided by N) [adm ctrl state] > * at some rate (PCN-lower-rate + adm-offset-rate), then pkts=20 > are marked at the same rate, even if the traffic rate climbs=20 > higher [adm ctrl state] > * when the traffic rate reaches the PCN-upper-rate,=20 > additional pkts are marked (additional marking rate =3D excess=20 > rate above PCN-upper-rate divided by N) [termination ctrl state] > * if pkts arrive already PCN-marked, then the node measures=20 > the rate of pkts already marked & works out what excess rate=20 > this corresponds to, and only marks additional pkts if its=20 > own excess rate is even higher.=20 > * the PCN-egress-node measures the rate of PCN-marked pkts=20 > and determines whether the overloaded node is in adm ctrl=20 > state or termination ctrl state >=20 >=20 > Questions: > - I don't understand the point of doing PCN-marking in the adm ctrl > state. When it comes to making an adm decision, you send a (single) > probe pkt - if it's PCN-marked or affected-marked then you block the > call. So when a node's in the adm ctrl state, it could just do > affected-marking of all pkts. Wouldn't that work just as well? > - with you current algo, imagine there are two paths through the nw:=20 > A-B-X-D > A-M-N-X-D > If B & N are both in adm ctrl state then they both will do=20 > PCN-marking. > At the PCN-egress-node the PCN-marking rate may be high enough that it > believes termination is needed. Are there topologies/scenarios where > this could happen? I think your multicongestion_error=20 > parameter in S3.4 > is connected to this problem; I didn't find your discussion about it > convincing > - the 'affected marking' is claimed to solve ECMP issues. However, the > same affected marking is used in both adm ctrl state &=20 > termination ctrl > state - I don't think this works. Imagine that a node [node-1] on one > path is in adm ctrl state & a node [node-2] on another path is in > termination ctrl state. Therefore flows are terminated, and only flows > that are being PCN-marked or affected-marked are terminated. However > this could lead to flows being terminated that go through=20 > node-1; node-2 > will still be just as badly overloaded.=20 > - in the termination algorithm, S4.2.2, the "termination_offset_rate" > factor makes no sense to me > - the parameters PCN_lower_rate_egress & PCN_upper_rate_egress are > expressed in the wrong units (you have conditions like > signalled_overload_rate > PCN_lower_rate_egress; the former is a rate, > the latter a % so some tweaking is needed to convert the latter into a > rate) >=20 > best wishes >=20 > phil/ >=20 > > -----Original Message----- > > From: Anurag Bhargava (RL/TNT) [mailto:anurag.bhargava@ericsson.com] > > Sent: 11 September 2007 12:36 > > To: pcn > > Subject: [PCN] LC-PCN version 01 uploaded > >=20 > > Hello, > > FYI - We have uploaded a new version of the PCN draft. The major > > changes are some clarification and adopting to the=20 > Architecture draft > > terminology. > >=20 > > "LC-PCN: The Load Control PCN Solution", Lars Westberg, 5-Sep-07, > > > >=20 > > Please let me know if you have any questions. > >=20 > > Thanks, > > -Anurag Bhargava, Ph.D. > >=20 > >=20 > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www1.ietf.org/mailman/listinfo/pcn >=20 >=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn >=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Oct 09 11:15:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfGn8-0007YO-PO; Tue, 09 Oct 2007 11:14:38 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IfGn7-0007YH-Ir for pcn-confirm+ok@megatron.ietf.org; Tue, 09 Oct 2007 11:14:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfGn7-0007Y9-9F for pcn@ietf.org; Tue, 09 Oct 2007 11:14:37 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfGn1-0002as-Ov for pcn@ietf.org; Tue, 09 Oct 2007 11:14:37 -0400 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l99FLkgY011918; Tue, 9 Oct 2007 10:21:51 -0500 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Oct 2007 10:13:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Oct 2007 10:13:38 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Questions on LC-PCN draft version 01 Thread-Index: AcfxoTfiMvYaDfTgQ9adZz5poNI4WwCxk0OgAGsQTGAEvbcRwABfCJzg References: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC4E4@E03MVZ1-UKDY.domain1.systemhost.net> From: "Anurag Bhargava" To: "Anna Charny (acharny)" , "Georgios Karagiannis" , "Lars Westberg" X-OriginalArrivalTime: 09 Oct 2007 15:13:41.0393 (UTC) FILETIME=[F9DC7810:01C80A86] X-Spam-Score: 0.0 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Cc: pcn@ietf.org Subject: [PCN] RE: Questions on LC-PCN draft version 01 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org I apologize for the delay. Please bear with me. I am compiling clarifications to Phil's and Anna's questions. I will send them to the list ASAP.=20 BR, -Anurag Bhargava, Ph.D. =20 >-----Original Message----- >From: Anna Charny (acharny) [mailto:acharny@cisco.com]=20 >Sent: Sunday, October 07, 2007 3:40 PM >To: Anurag Bhargava; Georgios Karagiannis; Lars Westberg >Cc: pcn@ietf.org >Subject: Questions on LC-PCN draft version 01 > >Dear authors of the LC-PCN draft, > >Am I right that there has been no response yet to Phil's=20 >questions (attached at the end) on the new version of your=20 >draft below (I checked the pcn list and it does not seem it=20 >went there)? If the response was sent, can you resend it please? > >I have many of the same questions, and also a few additional=20 >ones. Here are some of them. > >1) I do not understand whether pcn-lower_rate_egress and=20 >pcn_upper_rate ingress are expressed as a fraction of the=20 >total rate (a unitless entity, analogous to CLE) or an=20 >absolute value (in bits or bytes per second). The text seems=20 >to be contradictory on this point: =20 > >on page 8 it is a fraction: =20 > >"PCN_lower_rate_egress =3D predefined percentage of received=20 >PCN_marking", > >while on page 13 it is an absolute rate: > >"If the incoming_PCN_marking_rate is higher than a preconfigured > PCN_lower_rate_egress, ..." where the=20 > >(Incoming_PCN_marking_rate is clearly defined as abslolue rate on page >12: "Where the "incoming_PCN_marking_rate" is calculated as follows: >incoming_PCN_marking_rate =3D (received number of "PCN_marking"=20 >DSCP during T)* N)/T;) > >2) Regarding the question above,=20 > > * if pcn_lower_rate_eggress (and pcn_uppre-rate_egress) are=20 >absolute rates, then how do you choose that abslolute rate=20 >value, given that the rates of ingress-egress aggregates at=20 >the same ingress may be vastly different in magnitude? > > *if, however, pcn_lower_rate_eggress (and=20 >pcn_uppre-rate_egress) are ratios, then what is the guidance=20 >of setting these ratios so that the egress can always tell=20 >admission state from the termination state, given that the=20 >same marking is used for admission and termination marking? >Specifically, suppose at the bottleneck pcn_lower_threshold is=20 >set to X, and pcn_upper_threshold to aX with some a>1 (assume=20 >for example a=3D1.5). >How does the egress node tell between the conditions when the=20 >total pcn traffic on the bottleneck is 1.1X (which is the=20 >state wnen admission is needed but termination is not, - in=20 >this case (1.1X-X)/X=3D0.1 traffic is pcn-marked), and the case=20 >when the total traffic on the bottleneck is 1.1aX, which is=20 >the case when termination is needed, and (1.1ax-ax)/ax=3D0.1),=20 >if in both cases the ratio between marked and total traffic is=20 >the same value 0.1? > >3) On page 9, multicongestion error error is introduced, but=20 >the text is silent on how this error is defined and what is it=20 >set to (if it is a configuration parameter), or how it is=20 >measured (if it is something that is being measured). Can you=20 >explain, please? > >I have some more questions, including sharing those asked by=20 >Phil in the attached message), but I will stop now, as I hope=20 >clarifications on the above (and Phil's) questions will help=20 >understand the draft better... > >Thank you in advance for clarifying all this. > >Anna=20 > >> -----Original Message----- >> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] >> Sent: Thursday, September 13, 2007 11:27 AM >> To: anurag.bhargava@ericsson.com; pcn@ietf.org >> Subject: RE: [PCN] LC-PCN version 01 uploaded >>=20 >> Anurag >>=20 >> Thanks for the revised draft, I can understand it much better. Here=20 >> are some questions /misunderstandings. >>=20 >> Let me summarise to make sure I understand it right. >>=20 >> - two encodings are used. one ('PCN-marking') is used for both adm=20 >> ctrl & termination to indicate the excess traffic. >> If a PCN-interior-node is PCN-marking some pkts, then it marks all=20 >> other pkts with another encoding ('affected marking') >>=20 >> - the 'PCN-marking' algorithm has several regimes: >> * when traffic rate is below PCN-lower-rate, no pkts are marked >> * as the traffic rate climbs above the PCN-lower-rate, an increasing=20 >> number of pkts are marked (marking rate =3D excess rate divided by N) = >> [adm ctrl state] >> * at some rate (PCN-lower-rate + adm-offset-rate), then pkts are=20 >> marked at the same rate, even if the traffic rate climbs higher [adm=20 >> ctrl state] >> * when the traffic rate reaches the PCN-upper-rate, additional pkts=20 >> are marked (additional marking rate =3D excess rate above=20 >PCN-upper-rate=20 >> divided by N) [termination ctrl state] >> * if pkts arrive already PCN-marked, then the node measures the rate=20 >> of pkts already marked & works out what excess rate this corresponds=20 >> to, and only marks additional pkts if its own excess rate is even=20 >> higher. >> * the PCN-egress-node measures the rate of PCN-marked pkts and=20 >> determines whether the overloaded node is in adm ctrl state or=20 >> termination ctrl state >>=20 >>=20 >> Questions: >> - I don't understand the point of doing PCN-marking in the adm ctrl=20 >> state. When it comes to making an adm decision, you send a (single)=20 >> probe pkt - if it's PCN-marked or affected-marked then you block the=20 >> call. So when a node's in the adm ctrl state, it could just do=20 >> affected-marking of all pkts. Wouldn't that work just as well? >> - with you current algo, imagine there are two paths through the nw:=20 >> A-B-X-D >> A-M-N-X-D >> If B & N are both in adm ctrl state then they both will do=20 >> PCN-marking. >> At the PCN-egress-node the PCN-marking rate may be high=20 >enough that it=20 >> believes termination is needed. Are there topologies/scenarios where=20 >> this could happen? I think your multicongestion_error parameter in=20 >> S3.4 is connected to this problem; I didn't find your=20 >discussion about=20 >> it convincing >> - the 'affected marking' is claimed to solve ECMP issues.=20 >However, the=20 >> same affected marking is used in both adm ctrl state & termination=20 >> ctrl state - I don't think this works. Imagine that a node=20 >[node-1] on=20 >> one path is in adm ctrl state & a node [node-2] on another=20 >path is in=20 >> termination ctrl state. Therefore flows are terminated, and=20 >only flows=20 >> that are being PCN-marked or affected-marked are terminated. However=20 >> this could lead to flows being terminated that go through node-1;=20 >> node-2 will still be just as badly overloaded. >> - in the termination algorithm, S4.2.2, the "termination_offset_rate" >> factor makes no sense to me >> - the parameters PCN_lower_rate_egress & PCN_upper_rate_egress are=20 >> expressed in the wrong units (you have conditions like=20 >> signalled_overload_rate > PCN_lower_rate_egress; the former=20 >is a rate,=20 >> the latter a % so some tweaking is needed to convert the=20 >latter into a >> rate) >>=20 >> best wishes >>=20 >> phil/ >>=20 >> > -----Original Message----- >> > From: Anurag Bhargava (RL/TNT)=20 >[mailto:anurag.bhargava@ericsson.com] >> > Sent: 11 September 2007 12:36 >> > To: pcn >> > Subject: [PCN] LC-PCN version 01 uploaded >> >=20 >> > Hello, >> > FYI - We have uploaded a new version of the PCN draft. The major=20 >> > changes are some clarification and adopting to the >> Architecture draft >> > terminology. >> >=20 >> > "LC-PCN: The Load Control PCN Solution", Lars Westberg, 5-Sep-07, >> > >> >=20 >> > Please let me know if you have any questions. >> >=20 >> > Thanks, >> > -Anurag Bhargava, Ph.D. >> >=20 >> >=20 >> > _______________________________________________ >> > PCN mailing list >> > PCN@ietf.org >> > https://www1.ietf.org/mailman/listinfo/pcn >>=20 >>=20 >> _______________________________________________ >> PCN mailing list >> PCN@ietf.org >> https://www1.ietf.org/mailman/listinfo/pcn >>=20 > _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Oct 15 16:33:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhWcj-0004yz-JR; Mon, 15 Oct 2007 16:33:13 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IhWch-0004yo-Fj for pcn-confirm+ok@megatron.ietf.org; Mon, 15 Oct 2007 16:33:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhWcg-0004xs-GB for pcn@ietf.org; Mon, 15 Oct 2007 16:33:10 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhWcV-0002sF-8T for pcn@ietf.org; Mon, 15 Oct 2007 16:33:05 -0400 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l9FKWhIX026189 for ; Mon, 15 Oct 2007 15:32:43 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Oct 2007 15:32:42 -0500 Received: from [147.117.169.183] ([147.117.169.183]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Oct 2007 15:32:43 -0500 From: Steven Blake To: pcn Content-Type: multipart/mixed; boundary="=-BpLEEOcC4Wh8ExSsrj9g" Organization: Ericsson IP Infrastructure Date: Mon, 15 Oct 2007 16:32:42 -0400 Message-Id: <1192480362.4110.4.camel@neutrino> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) X-OriginalArrivalTime: 15 Oct 2007 20:32:43.0134 (UTC) FILETIME=[89B4D9E0:01C80F6A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Subject: [PCN] [Fwd: REVISED Internet-Draft Submission Cutoff Dates for the 70th IETF Meeting in Vancouver, BC, Canada] X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org --=-BpLEEOcC4Wh8ExSsrj9g Content-Type: text/plain Content-Transfer-Encoding: 7bit FYI =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven Blake Ericsson/Redback Networks +1 919-472-9913 --=-BpLEEOcC4Wh8ExSsrj9g Content-Disposition: inline Content-Description: Forwarded message - REVISED Internet-Draft Submission Cutoff Dates for the 70th IETF Meeting in Vancouver, BC, Canada Content-Type: message/rfc822 Return-path: Envelope-to: slblake@petri-meat.com Delivery-date: Fri, 12 Oct 2007 11:58:33 -0400 Received: from megatron.ietf.org ([156.154.16.145]) by elom.tchmachines.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1IgMuH-0007Rq-Ki for slblake@petri-meat.com; Fri, 12 Oct 2007 11:58:33 -0400 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgMhH-0001Ms-Kh; Fri, 12 Oct 2007 11:45:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgMhG-0001Jl-AH for ietf-announce@ietf.org; Fri, 12 Oct 2007 11:45:06 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgMhF-0002QM-VA for ietf-announce@ietf.org; Fri, 12 Oct 2007 11:45:06 -0400 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns1.neustar.com (Postfix) with ESMTP id CD0D226E66 for ; Fri, 12 Oct 2007 15:45:00 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1IgMhA-00025Z-OI for ietf-announce@ietf.org; Fri, 12 Oct 2007 11:45:00 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: IETF Announcement list Cc: From: IETF Secretariat Message-Id: Date: Fri, 12 Oct 2007 11:45:00 -0400 X-Spam-Score: -1.4 (-) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: REVISED Internet-Draft Submission Cutoff Dates for the 70th IETF Meeting in Vancouver, BC, Canada X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-announce-bounces@ietf.org Content-Transfer-Encoding: 7bit There are two (2) Internet-Draft cutoff dates for the 70th IETF Meeting in Vancouver, BC, Canada: November 12th: Cutoff Date for Initial (i.e., version -00) Internet-Draft Submissions All initial Internet-Drafts (version -00) must be submitted by Monday, November 12th at 9:00 AM ET (14:00 UTC/GMT). The only exception is for version -00 WG drafts that replace existing non-WG drafts. Such drafts may be submitted until the cutoff date for version -01 and higher drafts. As always, all initial submissions with a filename beginning with "draft-ietf" must be approved by the appropriate WG Chair before they can be processed or announced. The Secretariat would appreciate receiving WG Chair approval by Monday, November 5th at 9:00 AM ET (14:00 UTC/GMT). November 19th: Cutoff Date for Revised (i.e., version -01 and higher) Internet-Draft Submissions All revised Internet-Drafts (version -01 and higher) must be submitted by Monday, November 19th at 9:00 AM ET (14:00 UTC/GMT). Initial and revised Internet-Drafts submitted after their respective cutoff dates will not be made available in the Internet-Drafts directory or announced until on or after Monday, December 3rd at 9:00 AM ET (14:00 UTC/GMT), when Internet-Draft posting resumes. Please do not wait until the last minute to submit. The Secretariat encourages you to submit your Internet-Drafts via the Internet-Draft Submission Tool (IDST) https://datatracker.ietf.org/idst/upload.cgi. If you are unable to do so, then you may still submit your Internet-Drafts manually by sending them to internet-drafts@ietf.org. If you are submitting a version -00 WG draft that replaces non-WG draft, then you must submit it manually as the current IDST cannot handle replacements. Please be sure to state that one draft replaces another in the cover note that accompanies your submission. Also, please note that the IDST will not accept drafts submitted after their respective cutoff dates. Thank you for your understanding and cooperation. If you have any questions or concerns, then please send a message to internet-drafts@ietf.org. The IETF Secretariat FYI: The Internet-Draft cutoff dates as well as other significant dates for the 70th IETF Meeting can be found at http://www3.ietf.org/meetings/70-cutoff_dates.html. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce --=-BpLEEOcC4Wh8ExSsrj9g 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 --=-BpLEEOcC4Wh8ExSsrj9g-- From pcn-bounces@ietf.org Tue Oct 16 12:46:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhpY8-00068A-9s; Tue, 16 Oct 2007 12:45:44 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IhpY7-00066F-Ad for pcn-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 12:45:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhpY6-000646-Hj for pcn@ietf.org; Tue, 16 Oct 2007 12:45:42 -0400 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhpXx-0002t2-Th for pcn@ietf.org; Tue, 16 Oct 2007 12:45:40 -0400 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.63]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Oct 2007 17:45:13 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PCN] PCN architecture, revised sub-section on probing Date: Tue, 16 Oct 2007 17:45:13 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC5CC@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <4700E34B.4080000@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN architecture, revised sub-section on probing Thread-Index: AcgEJCiSRzpW4sBXSiGPeDp9P2ZdpAL7v/Fw From: To: , X-OriginalArrivalTime: 16 Oct 2007 16:45:13.0720 (UTC) FILETIME=[EC6F4F80:01C81013] X-Spam-Score: 0.0 (/) X-Scan-Signature: ff67cea9f7df2d77f61a364cea0926e8 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0050871087==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0050871087== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C81013.EC24DB83" This is a multi-part message in MIME format. ------_=_NextPart_001_01C81013.EC24DB83 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Rob =20 Thanks for the experience tip from nsis-land. I'd assumed that ecmp worked on source and destination IP addresses and port numbers, the protocol ID and the DSCP - therefore the pcn-egress-node can choose other bit(s) in pkt to distinguish probe from data. However, I hadn't thought about the general case where the pcn-egress doesn't know what fields ecmp might be working on [what the pkt classifiers are looking at] - then you're stuffed.=20 =20 phil -----Original Message----- From: Lars Westberg [mailto:Lars.westberg@ericsson.com]=20 Sent: 01 October 2007 13:09 To: Hancock, Robert Cc: pcn Subject: Re: [PCN] PCN architecture, revised sub-section on probing =20 hi Robert.=20 I think the task is to do something very simplistic and skip the compexity to other solutions. If you want to have something complex, one can use NSIS. I am very worried to go into the complexity swamp. -Lasse Hancock, Robert wrote: hi, a comment on probe messages: > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@nokia.com] > Sent: 29 September 2007 07:31 > To: ext Steven Blake > Cc: pcn > Subject: Re: [PCN] PCN architecture, revised sub-section on probing > > On 2007-9-28, at 21:15, ext Steven Blake wrote: > > If a probe packet for a PCN-managed flow is intended to follow the > > same ECMP path as the flow, then the probe packet has to > look exactly > > like flow packets in the header fields usually hashed by routers to > > load split for ECMP: IP source/destination address, TCP/UDP > > source/destination port; maybe the protocol/next header > field as well. > > > > If you do this, you are essentially spoofing traffic for the host > > originating the flow. I'm sure the security review > comments for this > > will make for entertaining reading. > > > > At the very least, you need to ensure that there is an *airtight* > > mechanism for ensuring that the probe traffic can never leak out of > > the PCN domain, and that no ICMP traffic can be sent back > towards the > > host. Having been through a very similar question in the context of another protocol, my feeling is that this level of 'faithfulness' in the probe messages at least is over-ambitious. There are conflicting requirements: - you accept that ECMP can load share on nearly anything, i.e. the interior packet classifiers can look far into the packet for fields to distinguish microflows, but - you rely on egress packet classifiers to look into the packet to find fields to disambiguate probe and real traffic It's hard to think of deployment approaches which would be robust in meeting these requirements. Even in a single deployment, there could be heterogeneous classification capabilities in the interior and edge routers. (For this circumstance at least, it would be nice if there was some guidance or baseline assumption on exactly how fine-grained it is sensible for things like ECMP to be. I'm not sure how practical that is, however.) robert h. > > Let me add that probe traffic (other than for supporting > ECMP) seems only useful when a domain can go from "no > congestion" to "must terminate" through the admission of a > very small number of flows.=20 > Otherwise, the gradual admission of regular flows can be used > to determine whether admission should be terminated. In other > words, regular flows can be used to "probe" the domain. > > I question whether domains that require explicit probing > mechanisms fall under the current PCN charter, which focuses > on domains that multiplex a sufficient numbers of flows such > that stateless, statistical mechanisms are effective. > > Explicit probing adds a lot of complexity. The idea behind > PCN is to add a minimal set of mechanisms to a large and busy > DiffServ domain, which would allow this domain to protect the > QoS of already-admitted flows in a best-effort sort of way. > Meaning that although flow termination should be mostly > prevented due to admission stop decisions, there will be no > guarantees that no flow will ever be terminated. PCN is also > not a mechanism to squeeze the last ounce of utilization out > of a domain - sufficient overprovisioning remains a > requirement. Because of this, I wonder if PCN needs to > support ECMP - which did not come up during the chartering > phase - when it looks likely that such support will > significantly complicate the solution. > > Finally, let me say that I'm worried that the WG seems to > have settled on a mode of working where all the different > proposals will be merged into one. The result is not likely > to be a very simple solution. We have ample experience with > solutions that have been designed in this manner failing to > gain any traction, due to their complexities. > > I'd like to strongly encourage the WG to instead discuss > which of the proposals is the most *simple* one that will > fulfill the chartered goals. We'd like the outcome of the > first phase of work to be something that people will usefully > deploy in some domains. Without demonstrated deployability > and use, the need for continued future work on PCN is questionable. > > Lars > > > _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn ------_=_NextPart_001_01C81013.EC24DB83 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [PCN] PCN architecture, revised sub-section on = probing

Rob

 

Thanks for the experience tip from = nsis-land. I’d assumed that ecmp worked on source and = destination IP addresses and port numbers, the protocol ID and the DSCP – = therefore the pcn-egress-node can choose other bit(s) in pkt to distinguish probe from = data. However, I hadn’t thought about the general case where the pcn-egress = doesn’t know what fields ecmp might be working on [what the pkt classifiers are = looking at] – then you’re stuffed.

 

phil

-----Origi= nal Message-----
From: Lars Westberg [mailto:Lars.westberg@ericsson.com]
Sent: 01 October 2007 13:09
To: Hancock, Robert
Cc: pcn
Subject: Re: [PCN] PCN architecture, revised sub-section on probing

 

hi Robert.

I think the task is to do something very simplistic and skip the = compexity to other solutions.
 If you want to have something complex, one can use NSIS. I am very worried to go into the complexity swamp.


-Lasse

Hancock, Robert wrote:

hi,

a comment on probe messages:

> -----Original Message-----
> From: Lars Eggert [mailto:lars.eggert@nokia.com] > Sent: 29 September 2007 07:31
> To: ext Steven Blake
> Cc: pcn
> Subject: Re: [PCN] PCN architecture, revised sub-section on = probing
>
> On 2007-9-28, at 21:15, ext Steven Blake wrote:
> > If a probe packet for a PCN-managed flow is intended to follow = the
> > same ECMP path as the flow, then the probe packet has to
> look exactly
> > like flow packets in the header fields usually hashed by = routers to
> > load split for ECMP: IP source/destination address, = TCP/UDP
> > source/destination port; maybe the protocol/next header
> field as well.
> >
> > If you do this, you are essentially spoofing traffic for the = host
> > originating the flow.  I'm sure the security review
> comments for this
> > will make for entertaining reading.
> >
> > At the very least, you need to ensure that there is an = *airtight*
> > mechanism for ensuring that the probe traffic can never leak = out of
> > the PCN domain, and that no ICMP traffic can be sent back
> towards the
> > host.

Having been through a very similar question in the context of = another
protocol, my feeling is that this level of 'faithfulness' in the
probe messages at least is over-ambitious. There are conflicting
requirements:

- you accept that ECMP can load share on nearly anything, i.e. the
interior packet classifiers can look far into the packet for fields
to distinguish microflows, but
- you rely on egress packet classifiers to look into the packet to
find fields to disambiguate probe and real traffic

It's hard to think of deployment approaches which would be robust
in meeting these requirements. Even in a single deployment, there
could be heterogeneous classification capabilities in the interior
and edge routers.

(For this circumstance at least, it would be nice if there was some
guidance or baseline assumption on exactly how fine-grained it is
sensible for things like ECMP to be. I'm not sure how practical
that is, however.)

robert h.

>
> Let me add that probe traffic (other than for supporting
> ECMP) seems only useful when a domain can go from "no
> congestion" to "must terminate" through the = admission of a
> very small number of flows. 
> Otherwise, the gradual admission of regular flows can be used
> to determine whether admission should be terminated. In other
> words, regular flows can be used to "probe" the = domain.
>
> I question whether domains that require explicit probing
> mechanisms fall under the current PCN charter, which focuses
> on domains that multiplex a sufficient numbers of flows such
> that stateless, statistical mechanisms are effective.
>
> Explicit probing adds a lot of complexity. The idea behind
> PCN is to add a minimal set of mechanisms to a large and busy
> DiffServ domain, which would allow this domain to protect the
> QoS of already-admitted flows in a best-effort sort of way.
> Meaning that although flow termination should be mostly
> prevented due to admission stop decisions, there will be no
> guarantees that no flow will ever be terminated. PCN is also
> not a mechanism to squeeze the last ounce of utilization out
> of a domain - sufficient overprovisioning remains a
> requirement. Because of this, I wonder if PCN needs to
> support ECMP - which did not come up during the chartering
> phase - when it looks likely that such support will
> significantly complicate the solution.
>
> Finally, let me say that I'm worried that the WG seems to
> have settled on a mode of working where all the different
> proposals will be merged into one. The result is not likely
> to be a very simple solution. We have ample experience with
> solutions that have been designed in this manner failing to
> gain any traction, due to their complexities.
>
> I'd like to strongly encourage the WG to instead discuss
> which of the proposals is the most *simple* one that will
> fulfill the chartered goals. We'd like the outcome of the
> first phase of work to be something that people will usefully
> deploy in some domains. Without demonstrated deployability
> and use, the need for continued future work on PCN is = questionable.
>
> Lars
>
>
>


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

=00 ------_=_NextPart_001_01C81013.EC24DB83-- --===============0050871087== 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 --===============0050871087==-- From pcn-bounces@ietf.org Tue Oct 16 13:01:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihpmy-0007vg-3v; Tue, 16 Oct 2007 13:01:04 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Ihpmx-0007vY-ID for pcn-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 13:01:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihpmw-0007rs-Jg for pcn@ietf.org; Tue, 16 Oct 2007 13:01:02 -0400 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ihpms-0004Ek-O3 for pcn@ietf.org; Tue, 16 Oct 2007 13:00:59 -0400 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.63]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Oct 2007 18:00:57 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 16 Oct 2007 18:00:55 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC5CD@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Architecture draft - probing section & general updates. Thread-Index: AcgQFh3bpdXKC6/iTqGKgTMqojS39g== From: To: X-OriginalArrivalTime: 16 Oct 2007 17:00:57.0189 (UTC) FILETIME=[1EC94150:01C81016] X-Spam-Score: 0.0 (/) X-Scan-Signature: 441502cf25997484ff0b8b79626c6b69 Subject: [PCN] Architecture draft - probing section & general updates. X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0726355913==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0726355913== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C81016.1E0329E8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C81016.1E0329E8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 There was quite a discussion about the probing section of the Architecture draft recently, draft-ietf-pcn-architecture-00. This showed to me that it needed a re-write, which I've attempted.=20 =20 One thing that struck me reading the discussion was that there really seem to be 2 uses of probing. The current draft tries to talk about them as though they're two aspects of the same thing; in the text below I've tried instead to talk about them separately - because I think they're really quite different. =20 The first uses probing to test the ingress-egress-aggregate, the second uses probing is to test a particular ECMP path. =20 The first uses probe pkts addressed to the PCN-egress-node, the second uses probe pkts addressed to the destination end node [so they follow the same ECMp path as the data pkts would do] =20 The first has no problem stopping probe pkts leaking out of the PCN-domain [because they're addressed to the PCN-egress-node] whilst the second has to think carefully about this [how the PCN-egress-node can easily identify pkts, but the ECMP algos are unaffected by the "flag =3D probe pkt"] =20 The first would probably be used by people who envisage probing rarely being used (most ingress-egress-aggregates always have traffic), the second is probably favoured by people who would actually probe on every call admission attempt [esp people who have it in mind to have PCN operating in parts of network with lower capacity links ie the multiple flows (aggregation) assumption doesn't hold]. (There are plenty of other scenarios which I'm not commenting on!) =20 The first has a less clear benefit to me (it doesn't seem that much better than the easy alternative - just admit the 'first' flow into an 'empty' ingress-egress-aggregate, and take the chance it causes flows to be terminated or pkts to be dropped). The second has a clearer benefit to me, in some scenarios (you test the actual ECMP path the flow would take.)=20 =20 The first probing approach (ie tests the ingress-egress-aggregate) seems to me quite simple to define, but the second much harder [need to work out how to stop probes leaking out of PCN-domain and how to flag a probe to minimise interactions with ECMP].=20 =20 Personally I think that in the short term (say until Christmas) our objective is to start converging on the router's PCN-marking behaviour (algorithm & encoding) - so it isn't necessary to talk about the details of probing at the moment. However, as part of the algorithm discussion it is relevant to note (as Michael has already pointed out) that excess-rate-marking algorithm is less suitable than a threshold-marking algo from a probing perspective (at least you have to send a lot more probe pkts to get an accurate picture of the pre-congestion level). (of course it's only one factor when we choose the algo.) =20 Anyway, here's the proposed revised sub-section 5.5 about probing - please comment /shout if you don't like it:- =20 **** Probing functions are optional, and can be used for admission control. =20 =20 PCN's admission control, as described so far, is essentially a reactive mechanism where the PCN-egress-node monitors the pre-congestion level for traffic from each PCN-ingress-node; if the level rises then it blocks new flows on that ingress-egress-aggregate. However, it's possible that an ingress-egress-aggregate carries no traffic, and so the PCN-egress-node can't make an admission decision using the usual method described earlier.=20 =20 One approach is to be "optimistic" and simply admit the new flow. However it's possible to envisage a scenario where the traffic levels on other ingress-egress-aggregates are already so high that they're blocking new PCN-flows and admitting a new flow onto this 'empty' ingress-egress-aggregate would add extra traffic onto the link that's already pre-congested - which may 'tip the balance' so that PCN's flow termination mechanism is activated or some packets are dropped. This risk could be lessened by configuring on each link sufficient 'safety margin' above the PCN-lower-rate. =20 =20 An alternative approach is to make PCN a more proactive mechanism. The PCN-ingress-node explicitly determines, before admitting the prospective new flow, whether the ingress-egress-aggregate can support it. This can be seen as a "pessimistic" approach, in contrast to the "optimism" of the approach above. It involves probing: a PCN-ingress-node generates and sends probe packets in order to test the pre-congestion level that the flow would experience. A probe packet is just a dummy data packet, generated by the PCN-ingress-node and addressed to the PCN-egress-node. A downside of probing is that it adds delay to the admission control process. Also note that in the scenario described in the previous paragraph (where traffic levels on other ingress-egress-aggregates is already very high), the probe packets may also 'tip the balance'. However, the risk should be reduced because it should be possible to send probe packets for a shorter time and at a lower rate than a typical data flow.=20 =20 The situation is more complicated if there is multipath routing (ECMP) in the PCN-domain. It is then possible for some paths to be pre-congested whilst other paths within the same ingress-egress-aggregate aren't pre-congested. =20 One approach essentially ignores ECMP: as usual, admit or block a new flow depending on the "measurements of PCN-traffic" on the ingress-egress-aggregate. This is rather similar to the "optimistic" approach above.=20 =20 An alternative ("pessimistic" or "proactive") approach is to probe the ECMP path. The PCN-ingress-node generates and sends probe packets (dummy data) that follow the specific ECMP path that the new flow would do, in order to test the pre-congestion level along it. An ECMP algorithm typically examines: the source and destination IP addresses and port numbers, the protocol ID and the DSCP. Hence these fields must have the same values in the probe packets as the future data packets would have. On the other hand, the PCN-egress-node needs to consume the probe packets to ensure that they don't travel beyond the PCN-domain (eg they might confuse the destination end node). Hence somehow the PCN-egress-node has to be able to disambiguate a probe packet from a data packet, via the characteristic setting of particular bit(s) in the packet's header or body - but these bit(s) mustn't be used by the PCN-node's ECMP algorithm.=20 =20 The probing functions are: =20 o Make decision that probing is needed. As described above, this is when the ingress-egress-aggregate or the ECMP path carries no PCN-traffic. An alternative is always to probe, ie probe before admitting every PCN-flow. =20 o (if required) Communicate the request that probing is needed - the PCN-egress-node signals to the PCN-ingress-node that probing is needed =20 o Generate probe traffic - the PCN-ingress-node generates the probe traffic. The appropriate number (or rate) of probe packets will depend on the PCN-marking algorithm; for example an excess-rate-marking algorithm generates fewer PCN-marks than a threshold-marking algorithm, and so will need more probe packets. =20 o Forward probe packets - as far as PCN-interior-nodes are concerned, probe packets must be handled the same as (ordinary data) PCN-packets, in terms of routing, scheduling and PCN-marking. =20 o Consume probe packets - the PCN-egress-node consumes probe packets to ensure that they don't travel beyond the PCN-domain. =20 **** =20 Incidentally, I have edited the draft to include all the comments /discussion that there's been on the list since Vancouver. I'll add the above probing section [unless there are cries of unhappiness]. I also have some comments on paper from bob [will summarise to list where > typos etc]. So will send revised version out next week or end of this week. =20 Best wishes phil ------_=_NextPart_001_01C81016.1E0329E8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

There was quite a discussion about the probing section of the Architecture draft recently, draft-ietf-pcn-architecture-00. This showed = to me that it needed a re-write, which I’ve attempted. =

 

One thing that struck me reading the discussion was that there = really seem to be 2 uses of probing. The current draft tries to talk about them = as though they’re two aspects of the same thing; in the text below = I’ve tried instead to talk about them separately – because I think = they’re really quite different.

 

The first uses probing to test the ingress-egress-aggregate, the = second uses probing is to test a particular ECMP path.

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

The first uses probe pkts addressed to the PCN-egress-node, the = second uses probe pkts addressed to the destination end node [so they follow the = same ECMp path as the data pkts would do]

 

The first has no problem stopping probe pkts leaking out of the PCN-domain [because they’re addressed to the PCN-egress-node] = whilst the second has to think carefully about this [how the PCN-egress-node can = easily identify pkts, but the ECMP algos are unaffected by the “flag =3D = probe pkt”]

 

The first would probably be used by people who envisage probing = rarely being used (most ingress-egress-aggregates always have traffic), the = second is probably favoured by people who would actually probe on every call admission = attempt [esp people who have it in mind to have PCN operating in parts of network = with lower capacity links ie the multiple flows (aggregation) assumption = doesn’t hold]. (There are plenty of other scenarios which I’m not commenting = on!)

 

The first has a less clear benefit to me (it doesn’t seem = that much better than the easy alternative - just admit the = ‘first’ flow into an ‘empty’ ingress-egress-aggregate, and take the = chance it causes flows to be terminated or pkts to be dropped). The second has a = clearer benefit to me, in some scenarios (you test the actual ECMP path the flow = would take.)

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

The first probing approach (ie tests the = ingress-egress-aggregate) seems to me quite simple to define, but the second much harder [need to work = out how to stop probes leaking out of PCN-domain and how to flag a probe to = minimise interactions with ECMP].

 

Personally I think that in the short term (say until Christmas) = our objective is to start converging on the router’s PCN-marking behaviour = (algorithm & encoding) – so it isn’t necessary to talk about the = details of probing at the moment. However, as part of the algorithm discussion = it is relevant to note (as Michael has already pointed out) that excess-rate-marking = algorithm is less suitable than a threshold-marking algo from a probing = perspective (at least you have to send a lot more probe pkts to get an accurate picture = of the pre-congestion level). (of course it’s only one factor when we choose the = algo.)

 

Anyway, here’s the proposed revised sub-section 5.5 about = probing – please comment /shout if you don’t like = it:-

 

****

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

 

PCN’s admission control, as described so far, is = essentially a reactive mechanism where the PCN-egress-node monitors the pre-congestion = level for traffic from each PCN-ingress-node; if the level rises then it = blocks new flows on that ingress-egress-aggregate. However, it’s possible = that an ingress-egress-aggregate carries no traffic, and so the PCN-egress-node can’t make an = admission decision using the usual method described earlier.

 

One approach is to be “optimistic” and simply admit = the new flow. However it’s possible to envisage a scenario where the = traffic levels on other ingress-egress-aggregates are already so high that = they’re blocking new PCN-flows and admitting a new flow onto this 'empty' ingress-egress-aggregate would add extra traffic onto the link = that’s already pre-congested – which may ‘tip the balance’ so = that PCN’s flow termination mechanism is activated or some packets are dropped. = This risk could be lessened by configuring on each link sufficient ‘safety = margin’ above the PCN-lower-rate.   

 

An alternative approach is to make PCN a more proactive = mechanism. The PCN-ingress-node explicitly determines, before admitting the prospective new flow, = whether the ingress-egress-aggregate can support it. This can be seen as a “pessimistic” = approach, in contrast to the “optimism” of the approach above. It = involves probing: a PCN-ingress-node generates and sends probe packets in order = to test the pre-congestion level that the flow would experience. A probe packet = is just a dummy data packet, generated by the PCN-ingress-node and addressed to = the PCN-egress-node. A downside of probing is that it adds delay to the admission control = process. Also note that in the scenario described in the previous paragraph (where = traffic levels on other ingress-egress-aggregates is already very high), the = probe packets may also ‘tip the balance’. However, the risk should = be reduced because it should be possible to send probe packets for a = shorter time and at a lower rate than a typical data flow.

 

The situation is more complicated if there is multipath routing = (ECMP) in the PCN-domain. It is then possible for some paths to be = pre-congested whilst other paths within the same ingress-egress-aggregate aren't = pre-congested.

 

One approach essentially ignores ECMP: as usual, admit or block = a new flow depending on the "measurements of PCN-traffic" on the = ingress-egress-aggregate. This is rather similar to the “optimistic” approach above. =

 

An alternative (“pessimistic” or = “proactive”) approach is to probe the ECMP path. The PCN-ingress-node generates and sends = probe packets (dummy data) that follow the specific ECMP path that the new = flow would do, in order to test the pre-congestion level along it. An ECMP = algorithm typically examines: the source and destination IP addresses and port = numbers, the protocol ID and the DSCP. Hence these fields must have the same = values in the probe packets as the future data packets would have. On the other = hand, the PCN-egress-node needs to consume the probe packets to ensure that they = don’t travel beyond the PCN-domain (eg they might confuse the destination end = node). Hence somehow the PCN-egress-node has to be able to disambiguate a probe = packet from a data packet, via the characteristic setting of particular bit(s) in = the packet’s header or body – but these bit(s) mustn’t be = used by the PCN-node’s ECMP algorithm.

 

The probing functions are:

 

   o  Make decision that probing is needed. As = described above, this is when the ingress-egress-aggregate or the ECMP path = carries no PCN-traffic. An alternative is always to probe, ie probe before = admitting every PCN-flow.

 

   o  (if required) Communicate the request that = probing is needed – the PCN-egress-node signals to the PCN-ingress-node = that probing is needed

 

   o  Generate probe traffic - the = PCN-ingress-node generates the probe traffic.  The appropriate number (or rate) of = probe packets will depend on the PCN-marking algorithm; for example an = excess-rate-marking algorithm generates fewer PCN-marks than a threshold-marking algorithm, = and so will need more probe packets.

 

   o  Forward probe packets - as far as PCN-interior-nodes are concerned, probe packets must be handled the same = as (ordinary data) PCN-packets, in terms of routing, scheduling and = PCN-marking.

 

   o  Consume probe packets - the PCN-egress-node consumes probe packets to ensure that they don't travel beyond the = PCN-domain.

 

****

 

Incidentally, I have edited the draft to include all the = comments /discussion that there’s been on the list since Vancouver. = I’ll add the above probing section [unless there are cries of unhappiness]. I = also have some comments on paper from bob [will summarise to list where > = typos etc]. So will send revised version out next week or end of this = week.

 

Best wishes

phil

=00 ------_=_NextPart_001_01C81016.1E0329E8-- --===============0726355913== 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 --===============0726355913==-- From pcn-bounces@ietf.org Tue Oct 16 13:48:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhqWl-0000qZ-41; Tue, 16 Oct 2007 13:48:23 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IhqWj-0000qS-Ip for pcn-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 13:48:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhqWi-0000qI-NW for pcn@ietf.org; Tue, 16 Oct 2007 13:48:20 -0400 Received: from rsys001x.roke.co.uk ([193.118.201.108]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhqWh-0007mq-O8 for pcn@ietf.org; Tue, 16 Oct 2007 13:48:20 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.13.1/8.13.1) with ESMTP id l9GHmFbo031846; Tue, 16 Oct 2007 18:48:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PCN] Architecture draft - probing section & general updates. Date: Tue, 16 Oct 2007 18:48:49 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Architecture draft - probing section & general updates. Thread-Index: AcgQFh3bpdXKC6/iTqGKgTMqojS39gABeF7A References: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC5CD@E03MVZ1-UKDY.domain1.systemhost.net> From: "Hancock, Robert" To: , X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 5655aae64318292c42757ebeb53e54ce Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0652161037==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0652161037== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8101C.BA6EDEB4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8101C.BA6EDEB4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable phil, =20 your text "Hence somehow the PCN-egress-node has to be able to disambiguate a probe packet from a data packet, via the characteristic setting of particular bit(s) in the packet's header or body - but these bit(s) mustn't be used by the PCN-node's ECMP algorithm." is nicely written (especially the "somehow").=20 =20 Presumably the last phrase should read "but these bit(s) mustn't be used by any interior PCN-node's ECMP algorithm." And there lies the rub: I can't see any robust technique that the ingress can use to decide what bits to set and how to set them, without the specification making explicit assumptions that go beyond what the ECMP "specifications" say, and which may not be compatible with filtering capabilities on the interior and egress nodes.=20 =20 robert h. ________________________________ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: 16 October 2007 18:01 To: pcn@ietf.org Subject: [PCN] Architecture draft - probing section & general updates. =09 =09 Hi, =20 There was quite a discussion about the probing section of the Architecture draft recently, draft-ietf-pcn-architecture-00. This showed to me that it needed a re-write, which I've attempted.=20 =20 One thing that struck me reading the discussion was that there really seem to be 2 uses of probing. The current draft tries to talk about them as though they're two aspects of the same thing; in the text below I've tried instead to talk about them separately - because I think they're really quite different. =20 The first uses probing to test the ingress-egress-aggregate, the second uses probing is to test a particular ECMP path. =09 The first uses probe pkts addressed to the PCN-egress-node, the second uses probe pkts addressed to the destination end node [so they follow the same ECMp path as the data pkts would do] =20 The first has no problem stopping probe pkts leaking out of the PCN-domain [because they're addressed to the PCN-egress-node] whilst the second has to think carefully about this [how the PCN-egress-node can easily identify pkts, but the ECMP algos are unaffected by the "flag =3D probe pkt"] =20 The first would probably be used by people who envisage probing rarely being used (most ingress-egress-aggregates always have traffic), the second is probably favoured by people who would actually probe on every call admission attempt [esp people who have it in mind to have PCN operating in parts of network with lower capacity links ie the multiple flows (aggregation) assumption doesn't hold]. (There are plenty of other scenarios which I'm not commenting on!) =20 The first has a less clear benefit to me (it doesn't seem that much better than the easy alternative - just admit the 'first' flow into an 'empty' ingress-egress-aggregate, and take the chance it causes flows to be terminated or pkts to be dropped). The second has a clearer benefit to me, in some scenarios (you test the actual ECMP path the flow would take.)=20 =09 The first probing approach (ie tests the ingress-egress-aggregate) seems to me quite simple to define, but the second much harder [need to work out how to stop probes leaking out of PCN-domain and how to flag a probe to minimise interactions with ECMP].=20 =20 Personally I think that in the short term (say until Christmas) our objective is to start converging on the router's PCN-marking behaviour (algorithm & encoding) - so it isn't necessary to talk about the details of probing at the moment. However, as part of the algorithm discussion it is relevant to note (as Michael has already pointed out) that excess-rate-marking algorithm is less suitable than a threshold-marking algo from a probing perspective (at least you have to send a lot more probe pkts to get an accurate picture of the pre-congestion level). (of course it's only one factor when we choose the algo.) =20 Anyway, here's the proposed revised sub-section 5.5 about probing - please comment /shout if you don't like it:- =20 **** Probing functions are optional, and can be used for admission control. =20 =20 PCN's admission control, as described so far, is essentially a reactive mechanism where the PCN-egress-node monitors the pre-congestion level for traffic from each PCN-ingress-node; if the level rises then it blocks new flows on that ingress-egress-aggregate. However, it's possible that an ingress-egress-aggregate carries no traffic, and so the PCN-egress-node can't make an admission decision using the usual method described earlier.=20 =20 One approach is to be "optimistic" and simply admit the new flow. However it's possible to envisage a scenario where the traffic levels on other ingress-egress-aggregates are already so high that they're blocking new PCN-flows and admitting a new flow onto this 'empty' ingress-egress-aggregate would add extra traffic onto the link that's already pre-congested - which may 'tip the balance' so that PCN's flow termination mechanism is activated or some packets are dropped. This risk could be lessened by configuring on each link sufficient 'safety margin' above the PCN-lower-rate. =20 =20 An alternative approach is to make PCN a more proactive mechanism. The PCN-ingress-node explicitly determines, before admitting the prospective new flow, whether the ingress-egress-aggregate can support it. This can be seen as a "pessimistic" approach, in contrast to the "optimism" of the approach above. It involves probing: a PCN-ingress-node generates and sends probe packets in order to test the pre-congestion level that the flow would experience. A probe packet is just a dummy data packet, generated by the PCN-ingress-node and addressed to the PCN-egress-node. A downside of probing is that it adds delay to the admission control process. Also note that in the scenario described in the previous paragraph (where traffic levels on other ingress-egress-aggregates is already very high), the probe packets may also 'tip the balance'. However, the risk should be reduced because it should be possible to send probe packets for a shorter time and at a lower rate than a typical data flow.=20 =20 The situation is more complicated if there is multipath routing (ECMP) in the PCN-domain. It is then possible for some paths to be pre-congested whilst other paths within the same ingress-egress-aggregate aren't pre-congested. =20 One approach essentially ignores ECMP: as usual, admit or block a new flow depending on the "measurements of PCN-traffic" on the ingress-egress-aggregate. This is rather similar to the "optimistic" approach above.=20 =20 An alternative ("pessimistic" or "proactive") approach is to probe the ECMP path. The PCN-ingress-node generates and sends probe packets (dummy data) that follow the specific ECMP path that the new flow would do, in order to test the pre-congestion level along it. An ECMP algorithm typically examines: the source and destination IP addresses and port numbers, the protocol ID and the DSCP. Hence these fields must have the same values in the probe packets as the future data packets would have. On the other hand, the PCN-egress-node needs to consume the probe packets to ensure that they don't travel beyond the PCN-domain (eg they might confuse the destination end node). Hence somehow the PCN-egress-node has to be able to disambiguate a probe packet from a data packet, via the characteristic setting of particular bit(s) in the packet's header or body - but these bit(s) mustn't be used by the PCN-node's ECMP algorithm.=20 =20 The probing functions are: =20 o Make decision that probing is needed. As described above, this is when the ingress-egress-aggregate or the ECMP path carries no PCN-traffic. An alternative is always to probe, ie probe before admitting every PCN-flow. =20 o (if required) Communicate the request that probing is needed - the PCN-egress-node signals to the PCN-ingress-node that probing is needed =20 o Generate probe traffic - the PCN-ingress-node generates the probe traffic. The appropriate number (or rate) of probe packets will depend on the PCN-marking algorithm; for example an excess-rate-marking algorithm generates fewer PCN-marks than a threshold-marking algorithm, and so will need more probe packets. =20 o Forward probe packets - as far as PCN-interior-nodes are concerned, probe packets must be handled the same as (ordinary data) PCN-packets, in terms of routing, scheduling and PCN-marking. =20 o Consume probe packets - the PCN-egress-node consumes probe packets to ensure that they don't travel beyond the PCN-domain. =20 **** =20 Incidentally, I have edited the draft to include all the comments /discussion that there's been on the list since Vancouver. I'll add the above probing section [unless there are cries of unhappiness]. I also have some comments on paper from bob [will summarise to list where > typos etc]. So will send revised version out next week or end of this week. =20 Best wishes phil ------_=_NextPart_001_01C8101C.BA6EDEB4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
phil,
 
your text
"Hence = somehow the=20 PCN-egress-node has to be able to disambiguate a probe packet from a = data=20 packet, via the characteristic setting of particular bit(s) in the = packet’s=20 header or body – but these bit(s) mustn’t be used by the = PCN-node’s ECMP=20 algorithm."
is nicely written (especially the "somehow").=20
 
Presumably the last phrase should read "but = these bit(s)=20 mustn't be used by any interior PCN-node's ECMP algorithm." And there = lies the=20 rub: I can't see any robust technique that the ingress can use to decide = what=20 bits to set and how to set them, without the specification making = explicit=20 assumptions that go beyond what the ECMP "specifications" say, and which = may not=20 be compatible with filtering capabilities on the interior and egress = nodes.=20
 
robert h.

From: philip.eardley@bt.com=20 [mailto:philip.eardley@bt.com]
Sent: 16 October 2007=20 18:01
To: pcn@ietf.org
Subject: [PCN] Architecture = draft -=20 probing section & general updates.

Hi,

 

There was quite a discussion about the = probing section=20 of the Architecture draft recently, draft-ietf-pcn-architecture-00. = This=20 showed to me that it needed a re-write, which I’ve attempted.=20

 

One thing that struck me reading the = discussion was=20 that there really seem to be 2 uses of probing. The current draft = tries to=20 talk about them as though they’re two aspects of the same thing; = in the text=20 below I’ve tried instead to talk about them separately – = because I think=20 they’re really quite different.

 

The first uses probing to test the=20 ingress-egress-aggregate, the second uses probing is to test a = particular ECMP=20 path.

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

The first uses probe pkts addressed to the=20 PCN-egress-node, the second uses probe pkts addressed to the = destination end=20 node [so they follow the same ECMp path as the data pkts would=20 do]

 

The first has no problem stopping probe pkts = leaking=20 out of the PCN-domain [because they’re addressed to the = PCN-egress-node]=20 whilst the second has to think carefully about this [how the = PCN-egress-node=20 can easily identify pkts, but the ECMP algos are unaffected by the = “flag =3D=20 probe pkt”]

 

The first would probably be used by people = who=20 envisage probing rarely being used (most ingress-egress-aggregates = always have=20 traffic), the second is probably favoured by people who would actually = probe=20 on every call admission attempt [esp people who have it in mind to = have PCN=20 operating in parts of network with lower capacity links ie the = multiple flows=20 (aggregation) assumption doesn’t hold]. (There are plenty of = other scenarios=20 which I’m not commenting on!)

 

The first has a less clear benefit to me (it = doesn’t=20 seem that much better than the easy alternative - just admit the = ‘first’ flow=20 into an ‘empty’ ingress-egress-aggregate, and take the = chance it causes flows=20 to be terminated or pkts to be dropped). The second has a clearer = benefit to=20 me, in some scenarios (you test the actual ECMP path the flow would = take.)=20

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

The first probing approach (ie tests the=20 ingress-egress-aggregate) seems to me quite simple to define, but the = second=20 much harder [need to work out how to stop probes leaking out of = PCN-domain and=20 how to flag a probe to minimise interactions with ECMP]. =

 

Personally I think that in the short term = (say until=20 Christmas) our objective is to start converging on the router’s = PCN-marking=20 behaviour (algorithm & encoding) – so it isn’t = necessary to talk about the=20 details of probing at the moment. However, as part of the algorithm = discussion=20 it is relevant to note (as Michael has already pointed out) that=20 excess-rate-marking algorithm is less suitable than a = threshold-marking algo=20 from a probing perspective (at least you have to send a lot more probe = pkts to=20 get an accurate picture of the pre-congestion level). (of course = it’s only one=20 factor when we choose the algo.)

 

Anyway, here’s the proposed revised = sub-section 5.5=20 about probing – please comment /shout if you don’t like = it:-

 

****

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

 

PCN’s admission control, as described = so far, is=20 essentially a reactive mechanism where the PCN-egress-node monitors = the=20 pre-congestion level for traffic from each PCN-ingress-node; if the = level=20 rises then it blocks new flows on that ingress-egress-aggregate. = However, it’s=20 possible that an ingress-egress-aggregate carries no traffic, and so = the=20 PCN-egress-node can’t make an admission decision using the usual = method=20 described earlier.

 

One approach is to be = “optimistic” and simply admit=20 the new flow. However it’s possible to envisage a scenario where = the traffic=20 levels on other ingress-egress-aggregates are already so high that = they’re=20 blocking new PCN-flows and admitting a new flow onto this 'empty'=20 ingress-egress-aggregate would add extra traffic onto the link = that’s already=20 pre-congested – which may ‘tip the balance’ so that = PCN’s flow termination=20 mechanism is activated or some packets are dropped. This risk could be = lessened by configuring on each link sufficient ‘safety = margin’ above the=20 PCN-lower-rate.   

 

An alternative approach is to make PCN a = more=20 proactive mechanism. The PCN-ingress-node explicitly determines, = before=20 admitting the prospective new flow, whether the = ingress-egress-aggregate can=20 support it. This can be seen as a “pessimistic” approach, = in contrast to the=20 “optimism” of the approach above. It involves probing: a = PCN-ingress-node=20 generates and sends probe packets in order to test the pre-congestion = level=20 that the flow would experience. A probe packet is just a dummy data = packet,=20 generated by the PCN-ingress-node and addressed to the = PCN-egress-node. A=20 downside of probing is that it adds delay to the admission control = process.=20 Also note that in the scenario described in the previous paragraph = (where=20 traffic levels on other ingress-egress-aggregates is already very = high), the=20 probe packets may also ‘tip the balance’. However, the = risk should be reduced=20 because it should be possible to send probe packets for a shorter time = and at=20 a lower rate than a typical data flow.

 

The situation is more complicated if there = is=20 multipath routing (ECMP) in the PCN-domain. It is then possible for = some paths=20 to be pre-congested whilst other paths within the same=20 ingress-egress-aggregate aren't pre-congested.

 

One approach essentially ignores ECMP: as = usual, admit=20 or block a new flow depending on the "measurements of PCN-traffic" on = the=20 ingress-egress-aggregate. This is rather similar to the = “optimistic” approach=20 above.

 

An alternative (“pessimistic” or = “proactive”) approach=20 is to probe the ECMP path. The PCN-ingress-node generates and sends = probe=20 packets (dummy data) that follow the specific ECMP path that the new = flow=20 would do, in order to test the pre-congestion level along it. An ECMP=20 algorithm typically examines: the source and destination IP addresses = and port=20 numbers, the protocol ID and the DSCP. Hence these fields must have = the same=20 values in the probe packets as the future data packets would have. On = the=20 other hand, the PCN-egress-node needs to consume the probe packets to = ensure=20 that they don’t travel beyond the PCN-domain (eg they might = confuse the=20 destination end node). Hence somehow the PCN-egress-node has to be = able to=20 disambiguate a probe packet from a data packet, via the characteristic = setting=20 of particular bit(s) in the packet’s header or body – but = these bit(s) mustn’t=20 be used by the PCN-node’s ECMP algorithm.

 

The probing functions are:

 

   o  Make decision that = probing is=20 needed. As described above, this is when the ingress-egress-aggregate = or the=20 ECMP path carries no PCN-traffic. An alternative is always to probe, = ie probe=20 before admitting every PCN-flow.

 

   o  (if required) = Communicate the=20 request that probing is needed – the PCN-egress-node signals to = the=20 PCN-ingress-node that probing is needed

 

   o  Generate probe traffic = - the=20 PCN-ingress-node generates the probe traffic.  The appropriate = number (or=20 rate) of probe packets will depend on the PCN-marking algorithm; for = example=20 an excess-rate-marking algorithm generates fewer PCN-marks than a=20 threshold-marking algorithm, and so will need more probe=20 packets.

 

   o  Forward probe packets - = as far as=20 PCN-interior-nodes are concerned, probe packets must be handled the = same as=20 (ordinary data) PCN-packets, in terms of routing, scheduling and=20 PCN-marking.

 

   o  Consume probe packets - = the=20 PCN-egress-node consumes probe packets to ensure that they don't = travel beyond=20 the PCN-domain.

 

****

 

Incidentally, I have edited the draft to = include all=20 the comments /discussion that there’s been on the list since=20 Vancouver. I’ll add the above probing section = [unless there are=20 cries of unhappiness]. I also have some comments on paper from bob = [will=20 summarise to list where > typos etc]. So will send revised version = out next=20 week or end of this week.

 

Best wishes

phil

------_=_NextPart_001_01C8101C.BA6EDEB4-- --===============0652161037== 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 --===============0652161037==-- From pcn-bounces@ietf.org Tue Oct 16 14:56:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihra2-0005kS-D6; Tue, 16 Oct 2007 14:55:50 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Ihra0-0005iR-1o for pcn-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 14:55:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhrZz-0005hr-5T for pcn@ietf.org; Tue, 16 Oct 2007 14:55:47 -0400 Received: from wrzx28.rz.uni-wuerzburg.de ([132.187.3.28] helo=mailrelay.rz.uni-wuerzburg.de) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhrZx-0001dj-RR for pcn@ietf.org; Tue, 16 Oct 2007 14:55:47 -0400 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 05488B473; Tue, 16 Oct 2007 20:55:43 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id EC04BB541; Tue, 16 Oct 2007 20:55:42 +0200 (CEST) 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 BA8C1B473; Tue, 16 Oct 2007 20:55:41 +0200 (CEST) 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 l9GItfh10838; Tue, 16 Oct 2007 20:55:41 +0200 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id EE9B96F591; Tue, 16 Oct 2007 20:48:31 +0200 (CEST) Message-ID: <47150885.70606@informatik.uni-wuerzburg.de> Date: Tue, 16 Oct 2007 20:52:53 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: philip.eardley@bt.com Subject: Re: [PCN] Architecture draft - probing section & general updates. References: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC5CD@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC5CD@E03MVZ1-UKDY.domain1.systemhost.net> Content-Type: text/plain; charset=windows-1252; format=flowed X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.2 (+) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 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: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Phil, I like your text as it reflects the current ideas about probing. It=20 nicely identifies the benefits and also the difficulties (that we were=20 always aware of!) of the two different types of probing. My view is to=20 first solve the easy tasks and then see whether there is a solution to=20 the more challenging objectives. It is good to have this section in the=20 architecture draft that the benefits of probing do not get lost on the=20 way to a first simple system. Regards, Michael philip.eardley@bt.com wrote: > > Hi, > > There was quite a discussion about the probing section of the=20 > Architecture draft recently, draft-ietf-pcn-architecture-00. This=20 > showed to me that it needed a re-write, which I=92ve attempted. > > One thing that struck me reading the discussion was that there really=20 > seem to be 2 uses of probing. The current draft tries to talk about=20 > them as though they=92re two aspects of the same thing; in the text=20 > below I=92ve tried instead to talk about them separately =96 because I=20 > think they=92re really quite different. > > The first uses probing to test the ingress-egress-aggregate, the=20 > second uses probing is to test a particular ECMP path. > > The first uses probe pkts addressed to the PCN-egress-node, the second=20 > uses probe pkts addressed to the destination end node [so they follow=20 > the same ECMp path as the data pkts would do] > > The first has no problem stopping probe pkts leaking out of the=20 > PCN-domain [because they=92re addressed to the PCN-egress-node] whilst=20 > the second has to think carefully about this [how the PCN-egress-node=20 > can easily identify pkts, but the ECMP algos are unaffected by the=20 > =93flag =3D probe pkt=94] > > The first would probably be used by people who envisage probing rarely=20 > being used (most ingress-egress-aggregates always have traffic), the=20 > second is probably favoured by people who would actually probe on=20 > every call admission attempt [esp people who have it in mind to have=20 > PCN operating in parts of network with lower capacity links ie the=20 > multiple flows (aggregation) assumption doesn=92t hold]. (There are=20 > plenty of other scenarios which I=92m not commenting on!) > > The first has a less clear benefit to me (it doesn=92t seem that much=20 > better than the easy alternative - just admit the =91first=92 flow into= an=20 > =91empty=92 ingress-egress-aggregate, and take the chance it causes flo= ws=20 > to be terminated or pkts to be dropped). The second has a clearer=20 > benefit to me, in some scenarios (you test the actual ECMP path the=20 > flow would take.) > > The first probing approach (ie tests the ingress-egress-aggregate)=20 > seems to me quite simple to define, but the second much harder [need=20 > to work out how to stop probes leaking out of PCN-domain and how to=20 > flag a probe to minimise interactions with ECMP]. > > Personally I think that in the short term (say until Christmas) our=20 > objective is to start converging on the router=92s PCN-marking behaviou= r=20 > (algorithm & encoding) =96 so it isn=92t necessary to talk about the=20 > details of probing at the moment. However, as part of the algorithm=20 > discussion it is relevant to note (as Michael has already pointed out)=20 > that excess-rate-marking algorithm is less suitable than a=20 > threshold-marking algo from a probing perspective (at least you have=20 > to send a lot more probe pkts to get an accurate picture of the=20 > pre-congestion level). (of course it=92s only one factor when we choose= =20 > the algo.) > > Anyway, here=92s the proposed revised sub-section 5.5 about probing =96= =20 > please comment /shout if you don=92t like it:- > > **** > > Probing functions are optional, and can be used for admission control. > > PCN=92s admission control, as described so far, is essentially a=20 > reactive mechanism where the PCN-egress-node monitors the=20 > pre-congestion level for traffic from each PCN-ingress-node; if the=20 > level rises then it blocks new flows on that ingress-egress-aggregate.=20 > However, it=92s possible that an ingress-egress-aggregate carries no=20 > traffic, and so the PCN-egress-node can=92t make an admission decision=20 > using the usual method described earlier. > > One approach is to be =93optimistic=94 and simply admit the new flow.=20 > However it=92s possible to envisage a scenario where the traffic levels= =20 > on other ingress-egress-aggregates are already so high that they=92re=20 > blocking new PCN-flows and admitting a new flow onto this 'empty'=20 > ingress-egress-aggregate would add extra traffic onto the link that=92s= =20 > already pre-congested =96 which may =91tip the balance=92 so that PCN=92= s flow=20 > termination mechanism is activated or some packets are dropped. This=20 > risk could be lessened by configuring on each link sufficient =91safety= =20 > margin=92 above the PCN-lower-rate. > > An alternative approach is to make PCN a more proactive mechanism. The=20 > PCN-ingress-node explicitly determines, before admitting the=20 > prospective new flow, whether the ingress-egress-aggregate can support=20 > it. This can be seen as a =93pessimistic=94 approach, in contrast to th= e=20 > =93optimism=94 of the approach above. It involves probing: a=20 > PCN-ingress-node generates and sends probe packets in order to test=20 > the pre-congestion level that the flow would experience. A probe=20 > packet is just a dummy data packet, generated by the PCN-ingress-node=20 > and addressed to the PCN-egress-node. A downside of probing is that it=20 > adds delay to the admission control process. Also note that in the=20 > scenario described in the previous paragraph (where traffic levels on=20 > other ingress-egress-aggregates is already very high), the probe=20 > packets may also =91tip the balance=92. However, the risk should be=20 > reduced because it should be possible to send probe packets for a=20 > shorter time and at a lower rate than a typical data flow. > > The situation is more complicated if there is multipath routing (ECMP)=20 > in the PCN-domain. It is then possible for some paths to be=20 > pre-congested whilst other paths within the same=20 > ingress-egress-aggregate aren't pre-congested. > > One approach essentially ignores ECMP: as usual, admit or block a new=20 > flow depending on the "measurements of PCN-traffic" on the=20 > ingress-egress-aggregate. This is rather similar to the =93optimistic=94= =20 > approach above. > > An alternative (=93pessimistic=94 or =93proactive=94) approach is to pr= obe the=20 > ECMP path. The PCN-ingress-node generates and sends probe packets=20 > (dummy data) that follow the specific ECMP path that the new flow=20 > would do, in order to test the pre-congestion level along it. An ECMP=20 > algorithm typically examines: the source and destination IP addresses=20 > and port numbers, the protocol ID and the DSCP. Hence these fields=20 > must have the same values in the probe packets as the future data=20 > packets would have. On the other hand, the PCN-egress-node needs to=20 > consume the probe packets to ensure that they don=92t travel beyond the= =20 > PCN-domain (eg they might confuse the destination end node). Hence=20 > somehow the PCN-egress-node has to be able to disambiguate a probe=20 > packet from a data packet, via the characteristic setting of=20 > particular bit(s) in the packet=92s header or body =96 but these bit(s)= =20 > mustn=92t be used by the PCN-node=92s ECMP algorithm. > > The probing functions are: > > o Make decision that probing is needed. As described above, this is=20 > when the ingress-egress-aggregate or the ECMP path carries no=20 > PCN-traffic. An alternative is always to probe, ie probe before=20 > admitting every PCN-flow. > > o (if required) Communicate the request that probing is needed =96 the=20 > PCN-egress-node signals to the PCN-ingress-node that probing is needed > > o Generate probe traffic - the PCN-ingress-node generates the probe=20 > traffic. The appropriate number (or rate) of probe packets will depend=20 > on the PCN-marking algorithm; for example an excess-rate-marking=20 > algorithm generates fewer PCN-marks than a threshold-marking=20 > algorithm, and so will need more probe packets. > > o Forward probe packets - as far as PCN-interior-nodes are concerned,=20 > probe packets must be handled the same as (ordinary data) PCN-packets,=20 > in terms of routing, scheduling and PCN-marking. > > o Consume probe packets - the PCN-egress-node consumes probe packets=20 > to ensure that they don't travel beyond the PCN-domain. > > **** > > Incidentally, I have edited the draft to include all the comments=20 > /discussion that there=92s been on the list since Vancouver. I=92ll add= =20 > the above probing section [unless there are cries of unhappiness]. I=20 > also have some comments on paper from bob [will summarise to list=20 > where > typos etc]. So will send revised version out next week or end=20 > of this week. > > Best wishes > > phil > > -----------------------------------------------------------------------= - > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn > =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 Tue Oct 16 14:56:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihra3-0005kg-ME; Tue, 16 Oct 2007 14:55:51 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Ihra1-0005jS-Cv for pcn-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 14:55:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihra0-0005jA-JJ for pcn@ietf.org; Tue, 16 Oct 2007 14:55:48 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhrZu-0000MZ-NZ for pcn@ietf.org; Tue, 16 Oct 2007 14:55:48 -0400 X-IronPort-AV: E=Sophos;i="4.21,284,1188792000"; d="scan'208,217";a="74153569" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 16 Oct 2007 14:55:37 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9GItaJ7009649; Tue, 16 Oct 2007 14:55:36 -0400 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 l9GItJkZ022392; Tue, 16 Oct 2007 18:55:32 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Oct 2007 14:55:29 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PCN] Architecture draft - probing section & general updates. Date: Tue, 16 Oct 2007 14:55:27 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Architecture draft - probing section & general updates. Thread-Index: AcgQFh3bpdXKC6/iTqGKgTMqojS39gABeF7AAAGUNqA= From: "Anna Charny (acharny)" To: "Hancock, Robert" , , X-OriginalArrivalTime: 16 Oct 2007 18:55:29.0395 (UTC) FILETIME=[1EF0AC30:01C81026] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15486.002 X-TM-AS-Result: No--20.423900-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=34729; t=1192560937; x=1193424937; 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]=20Architecture=20draft=20-=20probing=20section= 20&=20general=20updates. |Sender:=20 |To:=20=22Hancock, =20Robert=22=20, =20,=0A=20=20=20=20=20=20=20=20; bh=GKzL9d3pbLQal7yfKAE920AtYOZXKGUXwQM0P7MuPao=; b=kwxA3JZNjBynYsQxtCRYQnVd1SQgZssVIfWrppl6adKv2QYmCx2RVDv0vf81zXlqb0I/CpAy EwgxRfYNsLMZFf2JB6YuJGCQqSU0vjjcrpwIZxN6yQCDMt8MEVzxk2kq; Authentication-Results: rtp-dkim-1; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: cb256aa41b5300a7da304d7294799ef5 Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1348938991==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1348938991== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C81026.1EDBF8B8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C81026.1EDBF8B8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Robert, Phil, =20 Yes, Robert's is a fair concern to which no obvious solution is in sight. Different equipment might use different algorithms and might use different fields for ECMP load-balancing under different circumstances. IMHO this is a killer argument of why the use of probing for discovering the state of ECMP paths should not be considered within the scope of PCN WG. =20 =20 There remains a question of whether probing can/should be considerd to probe the path regardless of the ECMP issue. I see most of its value in flash crowd situations in combination with low ingress-egress agregation. =20 =20 Anna=20 ________________________________ From: Hancock, Robert [mailto:robert.hancock@roke.co.uk]=20 Sent: Tuesday, October 16, 2007 1:49 PM To: philip.eardley@bt.com; pcn@ietf.org Subject: RE: [PCN] Architecture draft - probing section & general updates. phil, =20 your text "Hence somehow the PCN-egress-node has to be able to disambiguate a probe packet from a data packet, via the characteristic setting of particular bit(s) in the packet's header or body - but these bit(s) mustn't be used by the PCN-node's ECMP algorithm." is nicely written (especially the "somehow").=20 =20 Presumably the last phrase should read "but these bit(s) mustn't be used by any interior PCN-node's ECMP algorithm." And there lies the rub: I can't see any robust technique that the ingress can use to decide what bits to set and how to set them, without the specification making explicit assumptions that go beyond what the ECMP "specifications" say, and which may not be compatible with filtering capabilities on the interior and egress nodes.=20 =20 robert h. ________________________________ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: 16 October 2007 18:01 To: pcn@ietf.org Subject: [PCN] Architecture draft - probing section & general updates. =09 =09 Hi, =20 There was quite a discussion about the probing section of the Architecture draft recently, draft-ietf-pcn-architecture-00. This showed to me that it needed a re-write, which I've attempted.=20 =20 One thing that struck me reading the discussion was that there really seem to be 2 uses of probing. The current draft tries to talk about them as though they're two aspects of the same thing; in the text below I've tried instead to talk about them separately - because I think they're really quite different. =20 The first uses probing to test the ingress-egress-aggregate, the second uses probing is to test a particular ECMP path. =09 The first uses probe pkts addressed to the PCN-egress-node, the second uses probe pkts addressed to the destination end node [so they follow the same ECMp path as the data pkts would do] =20 The first has no problem stopping probe pkts leaking out of the PCN-domain [because they're addressed to the PCN-egress-node] whilst the second has to think carefully about this [how the PCN-egress-node can easily identify pkts, but the ECMP algos are unaffected by the "flag =3D probe pkt"] =20 The first would probably be used by people who envisage probing rarely being used (most ingress-egress-aggregates always have traffic), the second is probably favoured by people who would actually probe on every call admission attempt [esp people who have it in mind to have PCN operating in parts of network with lower capacity links ie the multiple flows (aggregation) assumption doesn't hold]. (There are plenty of other scenarios which I'm not commenting on!) =20 The first has a less clear benefit to me (it doesn't seem that much better than the easy alternative - just admit the 'first' flow into an 'empty' ingress-egress-aggregate, and take the chance it causes flows to be terminated or pkts to be dropped). The second has a clearer benefit to me, in some scenarios (you test the actual ECMP path the flow would take.)=20 =09 The first probing approach (ie tests the ingress-egress-aggregate) seems to me quite simple to define, but the second much harder [need to work out how to stop probes leaking out of PCN-domain and how to flag a probe to minimise interactions with ECMP].=20 =20 Personally I think that in the short term (say until Christmas) our objective is to start converging on the router's PCN-marking behaviour (algorithm & encoding) - so it isn't necessary to talk about the details of probing at the moment. However, as part of the algorithm discussion it is relevant to note (as Michael has already pointed out) that excess-rate-marking algorithm is less suitable than a threshold-marking algo from a probing perspective (at least you have to send a lot more probe pkts to get an accurate picture of the pre-congestion level). (of course it's only one factor when we choose the algo.) =20 Anyway, here's the proposed revised sub-section 5.5 about probing - please comment /shout if you don't like it:- =20 **** Probing functions are optional, and can be used for admission control. =20 =20 PCN's admission control, as described so far, is essentially a reactive mechanism where the PCN-egress-node monitors the pre-congestion level for traffic from each PCN-ingress-node; if the level rises then it blocks new flows on that ingress-egress-aggregate. However, it's possible that an ingress-egress-aggregate carries no traffic, and so the PCN-egress-node can't make an admission decision using the usual method described earlier.=20 =20 One approach is to be "optimistic" and simply admit the new flow. However it's possible to envisage a scenario where the traffic levels on other ingress-egress-aggregates are already so high that they're blocking new PCN-flows and admitting a new flow onto this 'empty' ingress-egress-aggregate would add extra traffic onto the link that's already pre-congested - which may 'tip the balance' so that PCN's flow termination mechanism is activated or some packets are dropped. This risk could be lessened by configuring on each link sufficient 'safety margin' above the PCN-lower-rate. =20 =20 An alternative approach is to make PCN a more proactive mechanism. The PCN-ingress-node explicitly determines, before admitting the prospective new flow, whether the ingress-egress-aggregate can support it. This can be seen as a "pessimistic" approach, in contrast to the "optimism" of the approach above. It involves probing: a PCN-ingress-node generates and sends probe packets in order to test the pre-congestion level that the flow would experience. A probe packet is just a dummy data packet, generated by the PCN-ingress-node and addressed to the PCN-egress-node. A downside of probing is that it adds delay to the admission control process. Also note that in the scenario described in the previous paragraph (where traffic levels on other ingress-egress-aggregates is already very high), the probe packets may also 'tip the balance'. However, the risk should be reduced because it should be possible to send probe packets for a shorter time and at a lower rate than a typical data flow.=20 =20 The situation is more complicated if there is multipath routing (ECMP) in the PCN-domain. It is then possible for some paths to be pre-congested whilst other paths within the same ingress-egress-aggregate aren't pre-congested. =20 One approach essentially ignores ECMP: as usual, admit or block a new flow depending on the "measurements of PCN-traffic" on the ingress-egress-aggregate. This is rather similar to the "optimistic" approach above.=20 =20 An alternative ("pessimistic" or "proactive") approach is to probe the ECMP path. The PCN-ingress-node generates and sends probe packets (dummy data) that follow the specific ECMP path that the new flow would do, in order to test the pre-congestion level along it. An ECMP algorithm typically examines: the source and destination IP addresses and port numbers, the protocol ID and the DSCP. Hence these fields must have the same values in the probe packets as the future data packets would have. On the other hand, the PCN-egress-node needs to consume the probe packets to ensure that they don't travel beyond the PCN-domain (eg they might confuse the destination end node). Hence somehow the PCN-egress-node has to be able to disambiguate a probe packet from a data packet, via the characteristic setting of particular bit(s) in the packet's header or body - but these bit(s) mustn't be used by the PCN-node's ECMP algorithm.=20 =20 The probing functions are: =20 o Make decision that probing is needed. As described above, this is when the ingress-egress-aggregate or the ECMP path carries no PCN-traffic. An alternative is always to probe, ie probe before admitting every PCN-flow. =20 o (if required) Communicate the request that probing is needed - the PCN-egress-node signals to the PCN-ingress-node that probing is needed =20 o Generate probe traffic - the PCN-ingress-node generates the probe traffic. The appropriate number (or rate) of probe packets will depend on the PCN-marking algorithm; for example an excess-rate-marking algorithm generates fewer PCN-marks than a threshold-marking algorithm, and so will need more probe packets. =20 o Forward probe packets - as far as PCN-interior-nodes are concerned, probe packets must be handled the same as (ordinary data) PCN-packets, in terms of routing, scheduling and PCN-marking. =20 o Consume probe packets - the PCN-egress-node consumes probe packets to ensure that they don't travel beyond the PCN-domain. =20 **** =20 Incidentally, I have edited the draft to include all the comments /discussion that there's been on the list since Vancouver. I'll add the above probing section [unless there are cries of unhappiness]. I also have some comments on paper from bob [will summarise to list where > typos etc]. So will send revised version out next week or end of this week. =20 Best wishes phil ------_=_NextPart_001_01C81026.1EDBF8B8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Robert, Phil,
 
Yes, Robert's is a fair concern to which no = obvious=20 solution is in sight. Different equipment might use=20 different algorithms and might use different fields for ECMP = load-balancing=20 under different circumstances.  IMHO this is a killer argument of = why the=20 use of probing for discovering the state of ECMP paths should not be = considered=20 within the scope of PCN WG. 
 
There remains a question of whether probing = can/should be=20 considerd to probe the path regardless of the ECMP issue.  I see = most of=20 its value in flash crowd situations in combination with low = ingress-egress=20 agregation. 
 
Anna
From: = Hancock, Robert=20 [mailto:robert.hancock@roke.co.uk]
Sent: Tuesday, October 16, = 2007=20 1:49 PM
To: philip.eardley@bt.com; = pcn@ietf.org
Subject: RE:=20 [PCN] Architecture draft - probing section & general=20 updates.

phil,
 
your text
"Hence = somehow the=20 PCN-egress-node has to be able to disambiguate a probe packet from a = data=20 packet, via the characteristic setting of particular bit(s) in the = packet’s=20 header or body – but these bit(s) mustn’t be used by the = PCN-node’s ECMP=20 algorithm."
is nicely written (especially the "somehow"). =
 
Presumably the last phrase should read "but = these bit(s)=20 mustn't be used by any interior PCN-node's ECMP algorithm." And there = lies the=20 rub: I can't see any robust technique that the ingress can use to = decide what=20 bits to set and how to set them, without the specification making = explicit=20 assumptions that go beyond what the ECMP "specifications" say, and = which may=20 not be compatible with filtering capabilities on the interior and = egress=20 nodes.
 
robert h.

From: philip.eardley@bt.com=20 [mailto:philip.eardley@bt.com]
Sent: 16 October 2007=20 18:01
To: pcn@ietf.org
Subject: [PCN] = Architecture draft=20 - probing section & general updates.

Hi,

 

There was quite a discussion about the = probing=20 section of the Architecture draft recently, = draft-ietf-pcn-architecture-00.=20 This showed to me that it needed a re-write, which I’ve = attempted.=20

 

One thing that struck me reading the = discussion was=20 that there really seem to be 2 uses of probing. The current draft = tries to=20 talk about them as though they’re two aspects of the same = thing; in the text=20 below I’ve tried instead to talk about them separately – = because I think=20 they’re really quite different.

 

The first uses probing to test the=20 ingress-egress-aggregate, the second uses probing is to test a = particular=20 ECMP path.

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

The first uses probe pkts addressed to the = PCN-egress-node, the second uses probe pkts addressed to the = destination end=20 node [so they follow the same ECMp path as the data pkts would=20 do]

 

The first has no problem stopping probe = pkts leaking=20 out of the PCN-domain [because they’re addressed to the = PCN-egress-node]=20 whilst the second has to think carefully about this [how the = PCN-egress-node=20 can easily identify pkts, but the ECMP algos are unaffected by the = “flag =3D=20 probe pkt”]

 

The first would probably be used by people = who=20 envisage probing rarely being used (most ingress-egress-aggregates = always=20 have traffic), the second is probably favoured by people who would = actually=20 probe on every call admission attempt [esp people who have it in = mind to=20 have PCN operating in parts of network with lower capacity links ie = the=20 multiple flows (aggregation) assumption doesn’t hold]. (There = are plenty of=20 other scenarios which I’m not commenting = on!)

 

The first has a less clear benefit to me = (it doesn’t=20 seem that much better than the easy alternative - just admit the = ‘first’=20 flow into an ‘empty’ ingress-egress-aggregate, and take = the chance it causes=20 flows to be terminated or pkts to be dropped). The second has a = clearer=20 benefit to me, in some scenarios (you test the actual ECMP path the = flow=20 would take.)

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

The first probing approach (ie tests the=20 ingress-egress-aggregate) seems to me quite simple to define, but = the second=20 much harder [need to work out how to stop probes leaking out of = PCN-domain=20 and how to flag a probe to minimise interactions with ECMP].=20

 

Personally I think that in the short term = (say until=20 Christmas) our objective is to start converging on the = router’s PCN-marking=20 behaviour (algorithm & encoding) – so it isn’t = necessary to talk about=20 the details of probing at the moment. However, as part of the = algorithm=20 discussion it is relevant to note (as Michael has already pointed = out) that=20 excess-rate-marking algorithm is less suitable than a = threshold-marking algo=20 from a probing perspective (at least you have to send a lot more = probe pkts=20 to get an accurate picture of the pre-congestion level). (of course = it’s=20 only one factor when we choose the algo.)

 

Anyway, here’s the proposed revised = sub-section 5.5=20 about probing – please comment /shout if you don’t like=20 it:-

 

****

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

 

PCN’s admission control, as = described so far, is=20 essentially a reactive mechanism where the PCN-egress-node monitors = the=20 pre-congestion level for traffic from each PCN-ingress-node; if the = level=20 rises then it blocks new flows on that ingress-egress-aggregate. = However,=20 it’s possible that an ingress-egress-aggregate carries no = traffic, and so=20 the PCN-egress-node can’t make an admission decision using the = usual method=20 described earlier.

 

One approach is to be = “optimistic” and simply admit=20 the new flow. However it’s possible to envisage a scenario = where the traffic=20 levels on other ingress-egress-aggregates are already so high that = they’re=20 blocking new PCN-flows and admitting a new flow onto this 'empty'=20 ingress-egress-aggregate would add extra traffic onto the link = that’s=20 already pre-congested – which may ‘tip the = balance’ so that PCN’s flow=20 termination mechanism is activated or some packets are dropped. This = risk=20 could be lessened by configuring on each link sufficient = ‘safety margin’=20 above the PCN-lower-rate.   

 

An alternative approach is to make PCN a = more=20 proactive mechanism. The PCN-ingress-node explicitly determines, = before=20 admitting the prospective new flow, whether the = ingress-egress-aggregate can=20 support it. This can be seen as a “pessimistic” = approach, in contrast to the=20 “optimism” of the approach above. It involves probing: a = PCN-ingress-node=20 generates and sends probe packets in order to test the = pre-congestion level=20 that the flow would experience. A probe packet is just a dummy data = packet,=20 generated by the PCN-ingress-node and addressed to the = PCN-egress-node. A=20 downside of probing is that it adds delay to the admission control = process.=20 Also note that in the scenario described in the previous paragraph = (where=20 traffic levels on other ingress-egress-aggregates is already very = high), the=20 probe packets may also ‘tip the balance’. However, the = risk should be=20 reduced because it should be possible to send probe packets for a = shorter=20 time and at a lower rate than a typical data flow. =

 

The situation is more complicated if there = is=20 multipath routing (ECMP) in the PCN-domain. It is then possible for = some=20 paths to be pre-congested whilst other paths within the same=20 ingress-egress-aggregate aren't pre-congested.

 

One approach essentially ignores ECMP: as = usual,=20 admit or block a new flow depending on the "measurements of = PCN-traffic" on=20 the ingress-egress-aggregate. This is rather similar to the = “optimistic”=20 approach above.

 

An alternative (“pessimistic” = or “proactive”)=20 approach is to probe the ECMP path. The PCN-ingress-node generates = and sends=20 probe packets (dummy data) that follow the specific ECMP path that = the new=20 flow would do, in order to test the pre-congestion level along it. = An ECMP=20 algorithm typically examines: the source and destination IP = addresses and=20 port numbers, the protocol ID and the DSCP. Hence these fields must = have the=20 same values in the probe packets as the future data packets would = have. On=20 the other hand, the PCN-egress-node needs to consume the probe = packets to=20 ensure that they don’t travel beyond the PCN-domain (eg they = might confuse=20 the destination end node). Hence somehow the PCN-egress-node has to = be able=20 to disambiguate a probe packet from a data packet, via the = characteristic=20 setting of particular bit(s) in the packet’s header or body = – but these=20 bit(s) mustn’t be used by the PCN-node’s ECMP algorithm. =

 

The probing functions = are:

 

   o  Make decision that = probing is=20 needed. As described above, this is when the = ingress-egress-aggregate or the=20 ECMP path carries no PCN-traffic. An alternative is always to probe, = ie=20 probe before admitting every PCN-flow.

 

   o  (if required) = Communicate the=20 request that probing is needed – the PCN-egress-node signals = to the=20 PCN-ingress-node that probing is needed

 

   o  Generate probe = traffic - the=20 PCN-ingress-node generates the probe traffic.  The appropriate = number=20 (or rate) of probe packets will depend on the PCN-marking algorithm; = for=20 example an excess-rate-marking algorithm generates fewer PCN-marks = than a=20 threshold-marking algorithm, and so will need more probe=20 packets.

 

   o  Forward probe packets = - as far=20 as PCN-interior-nodes are concerned, probe packets must be handled = the same=20 as (ordinary data) PCN-packets, in terms of routing, scheduling and=20 PCN-marking.

 

   o  Consume probe packets = - the=20 PCN-egress-node consumes probe packets to ensure that they don't = travel=20 beyond the PCN-domain.

 

****

 

Incidentally, I have edited the draft to = include all=20 the comments /discussion that there’s been on the list since=20 Vancouver. I’ll add the above probing section = [unless there=20 are cries of unhappiness]. I also have some comments on paper from = bob [will=20 summarise to list where > typos etc]. So will send revised = version out=20 next week or end of this week.

 

Best wishes

phil

------_=_NextPart_001_01C81026.1EDBF8B8-- --===============1348938991== 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 --===============1348938991==-- From pcn-bounces@ietf.org Fri Oct 19 09:00:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IirT2-000735-DB; Fri, 19 Oct 2007 09:00:44 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IirT0-00071k-M5 for pcn-confirm+ok@megatron.ietf.org; Fri, 19 Oct 2007 09:00:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IirSz-00070T-EQ for pcn@ietf.org; Fri, 19 Oct 2007 09:00:41 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IirSy-0002UI-Sj for pcn@ietf.org; Fri, 19 Oct 2007 09:00:41 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9JD0WHg007843; Fri, 19 Oct 2007 16:00:36 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Oct 2007 15:58:28 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh103.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Oct 2007 15:58:27 +0300 Received: from [172.21.34.110] (esdhcp034110.research.nokia.com [172.21.34.110]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9JCwQVE001319; Fri, 19 Oct 2007 15:58:26 +0300 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <425EB9B7-F7DB-4895-9A68-47C0F709D196@nokia.com> From: Lars Eggert Subject: Re: [PCN] Architecture draft - probing section & general updates. Date: Fri, 19 Oct 2007 15:58:26 +0300 To: ext Anna Charny (acharny) X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 19 Oct 2007 12:58:27.0902 (UTC) FILETIME=[BDF97DE0:01C8124F] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1027957736==" Errors-To: pcn-bounces@ietf.org --===============1027957736== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-50--256858449; protocol="application/pkcs7-signature" --Apple-Mail-50--256858449 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-10-16, at 21:55, ext Anna Charny (acharny) wrote: > Yes, Robert's is a fair concern to which no obvious solution is in > sight. Different equipment might use different algorithms and might > use > different fields for ECMP load-balancing under different > circumstances. > IMHO this is a killer argument of why the use of probing for > discovering > the state of ECMP paths should not be considered within the scope > of PCN > WG. Agreed. > There remains a question of whether probing can/should be considerd to > probe the path regardless of the ECMP issue. I see most of its > value in > flash crowd situations in combination with low ingress-egress > agregation. I note that scenarios with low aggregation aren't in scope of the charter: The initial scope of the PCN WG is restricted by the following assumptions: ... (C) the number of flows across any potential aggregation bottleneck is sufficiently large for stateless, statistical mechanisms to be effective Lars --Apple-Mail-50--256858449 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzEwMTkxMjU4MjZaMCMGCSqGSIb3DQEJBDEWBBR1r+TDdqo4fQ6V EEychWMf1AhozDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAGde0Yx/hMdC8e8uHqP+w/2O626+szIxZW07pxeHXg7XWOxi+vIX7 hPsT9nI/Y0IZu5tvZ/JP2yW1scHL05wI2jTzWAtu3kmARibc3tz5WvWLeFLuvJyn0PH+AGssSXhM fG6TP/DzcfNK0hxw42mO0g3XkAlGXXdmgJxRjuR9iuQKMyCSSNid+h68wQZ7eiTwdMN0hTU9Awbl pW/Dz9/Jeg/hifY54UTtLCuhofMwwFDvj97AYr0UFXckoNhAO5sEYLPQ8SjYabKKL92U1OuarJ7P 9465c6/jFsmeVVqMzU+a65KCG/l/Ym7W6yHRx8nkXCXLMLaI0SQ0FMu1cxqt1wAAAAAAAA== --Apple-Mail-50--256858449-- --===============1027957736== 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 --===============1027957736==-- From pcn-bounces@ietf.org Fri Oct 19 09:23:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iiroo-0003SW-Vz; Fri, 19 Oct 2007 09:23:15 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Iiroo-0003Rd-9G for pcn-confirm+ok@megatron.ietf.org; Fri, 19 Oct 2007 09:23:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iirom-0003QO-In for pcn@ietf.org; Fri, 19 Oct 2007 09:23:13 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iirol-0007Ua-DJ for pcn@ietf.org; Fri, 19 Oct 2007 09:23:12 -0400 X-IronPort-AV: E=Sophos;i="4.21,300,1188792000"; d="scan'208";a="135200523" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 19 Oct 2007 09:23:11 -0400 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 l9JDNBGl005849; Fri, 19 Oct 2007 09:23:11 -0400 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 l9JDN58b016908; Fri, 19 Oct 2007 13:23:11 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Oct 2007 09:23:03 -0400 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] Architecture draft - probing section & general updates. Date: Fri, 19 Oct 2007 09:23:02 -0400 Message-ID: In-Reply-To: <425EB9B7-F7DB-4895-9A68-47C0F709D196@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Architecture draft - probing section & general updates. Thread-Index: AcgSUBT+aymtm9fVToiQGCN1HeZKlQAAC8jQ From: "Anna Charny (acharny)" To: "Lars Eggert" X-OriginalArrivalTime: 19 Oct 2007 13:23:03.0496 (UTC) FILETIME=[2D7F4480:01C81253] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15492.000 X-TM-AS-Result: No--26.936300-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3248; t=1192800191; x=1193664191; 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]=20Architecture=20draft=20-=20probing=20section= 20&=20general=20updates. |Sender:=20 |To:=20=22Lars=20Eggert=22=20; bh=cGnGFeLDNkUtuxNkT39EkI/zNbzIIGD+31nMDKDeDeA=; b=QAowZGxKf3kRKiC7fvsFIQJY+EnEMdQ9f5ZbARiQDYB06GAm+HRYWOmUQljcQ5HqSTbyaYwX Y+F/kQvJw2ywF6TJo1F/DxF0Uaf2vLmsTxxZzMz0dtgyhOa7N9pYAbGe; Authentication-Results: rtp-dkim-1; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Lars, On the low agfgregation point, please see below:=20 > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@nokia.com]=20 > Sent: Friday, October 19, 2007 8:58 AM > To: Anna Charny (acharny) > Cc: Hancock, Robert; philip.eardley@bt.com; pcn@ietf.org > Subject: Re: [PCN] Architecture draft - probing section &=20 > general updates. >=20 > On 2007-10-16, at 21:55, ext Anna Charny (acharny) wrote: > > Yes, Robert's is a fair concern to which no obvious solution is in=20 > > sight. Different equipment might use different algorithms and might=20 > > use different fields for ECMP load-balancing under different=20 > > circumstances. > > IMHO this is a killer argument of why the use of probing for=20 > > discovering the state of ECMP paths should not be considered within=20 > > the scope of PCN WG. >=20 > Agreed. >=20 > > There remains a question of whether probing can/should be=20 > considerd to=20 > > probe the path regardless of the ECMP issue. I see most of=20 > its value=20 > > in flash crowd situations in combination with low ingress-egress=20 > > agregation. >=20 > I note that scenarios with low aggregation aren't in scope of the > charter: >=20 > The initial scope of the PCN WG is restricted by the following > assumptions: > ... > (C) the number of flows across any potential aggregation bottleneck > is sufficiently large for stateless, statistical mechanisms > to be effective Actually, I did not mean low aggregation *at the bottleneck*, which is what the charter seems to restrict. Rather I meant the case when the bottleneck has high aggregation, but traffic on that bottleneck comes from a large number of ingress-egress pairs, each having very low aggregation levels. I believe technically the charter does put any explicit restrictions on the scope for ingress-egress aggregation.=20 Perhaps the WG should consider whether it is reasonable to impose restrictions on the *ingress-egress* aggregation levels as well. An argument can be made that in practice a large number of ingress-egress pairs may only have a few flows, even when the bottleneck aggregations are large.=20 The decision on whether low ingress-egress aggregation level is in scope seems to be important for choosing among the various approaches proposed to the WG, as some of them are substantially more sensitive to the low ingress-egress aggregations than others (e.g. single marking does not perform well at very low levels of aggregation, as we showed at the last meeting). =20 Perhaps an explicit discussion on the assumptions regarding the expected levels of ingress-egress aggregations is needed on the list?=20 Towards that discussion, my personal view is that in the long range ignoring low levels of ingress-egress aggregation levels will severely limit the viability/usefulness of the technology. However, perhaps as an initial step it would be OK to assume moderate to high aggregation levels, as long as a clear path is visible on how to address low aggregations in the future within the scope of defined behaviors. But I think it is important to have a clear consensus on this point.=20 Anna=20 >=20 > Lars >=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Oct 19 09:25:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iirr2-0006mu-4a; Fri, 19 Oct 2007 09:25:32 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Iirqz-0006ga-8o for pcn-confirm+ok@megatron.ietf.org; Fri, 19 Oct 2007 09:25:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iirqy-0006dw-6g for pcn@ietf.org; Fri, 19 Oct 2007 09:25:28 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iirqx-00041n-Mr for pcn@ietf.org; Fri, 19 Oct 2007 09:25:28 -0400 X-IronPort-AV: E=Sophos;i="4.21,300,1188792000"; d="scan'208";a="74325152" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 19 Oct 2007 09:25:27 -0400 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 l9JDPREu006590; Fri, 19 Oct 2007 09:25:27 -0400 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 l9JDPE8j017767; Fri, 19 Oct 2007 13:25:27 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Oct 2007 09:25:20 -0400 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: Correction: RE: [PCN] Architecture draft - probing section & general updates. Date: Fri, 19 Oct 2007 09:25:19 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Correction: RE: [PCN] Architecture draft - probing section & general updates. Thread-Index: AcgSUBT+aymtm9fVToiQGCN1HeZKlQAAC8jQAADCIFA= From: "Anna Charny (acharny)" To: "Anna Charny (acharny)" , "Lars Eggert" X-OriginalArrivalTime: 19 Oct 2007 13:25:20.0992 (UTC) FILETIME=[7F737E00:01C81253] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15492.000 X-TM-AS-Result: No--28.039000-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3970; t=1192800327; x=1193664327; 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:=20Correction=3A=20RE=3A=20[PCN]=20Architecture=20draft=20-=20pr obing=20section=20&=20general=20updates. |Sender:=20 |To:=20=22Anna=20Charny=20(acharny)=22=20, =0A=20=20=20 =20=20=20=20=20=22Lars=20Eggert=22=20; bh=NgwpxDC8s+WVrxNq5/CrhX5Ah1xzzDZRwb/O1WsAI1o=; b=CwNTZuMdAEC98D/ocncV8xxrGtTimUBr1iDzbfojsRG4+VosgLd8azZEb2Dl9eOkf8tEclkV kpleLR+1UuDi3wYR7nlitgDICsJuFY7KGKauqyf0Ug4tdy3ffVkHFo+j; 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: 5011df3e2a27abcc044eaa15befcaa87 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org A typo in my previous message: I meant to say the charter does NOT restrict the low ingress-egress aggregation. Edited the appropriate sentense below... Anna > -----Original Message----- > From: Anna Charny (acharny)=20 > Sent: Friday, October 19, 2007 9:23 AM > To: 'Lars Eggert' > Cc: Hancock, Robert; philip.eardley@bt.com; pcn@ietf.org > Subject: RE: [PCN] Architecture draft - probing section &=20 > general updates. >=20 > Hi Lars, >=20 > On the low agfgregation point, please see below:=20 >=20 > > -----Original Message----- > > From: Lars Eggert [mailto:lars.eggert@nokia.com] > > Sent: Friday, October 19, 2007 8:58 AM > > To: Anna Charny (acharny) > > Cc: Hancock, Robert; philip.eardley@bt.com; pcn@ietf.org > > Subject: Re: [PCN] Architecture draft - probing section & general=20 > > updates. > >=20 > > On 2007-10-16, at 21:55, ext Anna Charny (acharny) wrote: > > > Yes, Robert's is a fair concern to which no obvious=20 > solution is in=20 > > > sight. Different equipment might use different algorithms=20 > and might=20 > > > use different fields for ECMP load-balancing under different=20 > > > circumstances. > > > IMHO this is a killer argument of why the use of probing for=20 > > > discovering the state of ECMP paths should not be=20 > considered within=20 > > > the scope of PCN WG. > >=20 > > Agreed. > >=20 > > > There remains a question of whether probing can/should be > > considerd to > > > probe the path regardless of the ECMP issue. I see most of > > its value > > > in flash crowd situations in combination with low ingress-egress=20 > > > agregation. > >=20 > > I note that scenarios with low aggregation aren't in scope of the > > charter: > >=20 > > The initial scope of the PCN WG is restricted by the following > > assumptions: > > ... > > (C) the number of flows across any potential aggregation=20 > bottleneck > > is sufficiently large for stateless, statistical mechanisms > > to be effective >=20 > Actually, I did not mean low aggregation *at the=20 > bottleneck*, which is what the charter seems to restrict. =20 > Rather I meant the case when the bottleneck has high=20 > aggregation, but traffic on that bottleneck comes from a=20 > large number of ingress-egress pairs, each having very low=20 > aggregation levels. I believe technically the charter does NOT=20 > put any explicit restrictions on the scope for ingress-egress=20 > aggregation.=20 >=20 > Perhaps the WG should consider whether it is reasonable to=20 > impose restrictions on the *ingress-egress* aggregation=20 > levels as well. An argument can be made that in practice a=20 > large number of ingress-egress pairs may only have a few=20 > flows, even when the bottleneck aggregations are large.=20 >=20 > The decision on whether low ingress-egress aggregation level=20 > is in scope seems to be important for choosing among the=20 > various approaches proposed to the WG, as some of them are=20 > substantially more sensitive to the low ingress-egress=20 > aggregations than others (e.g. single marking does not=20 > perform well at very low levels of aggregation, as we showed=20 > at the last meeting). =20 >=20 > Perhaps an explicit discussion on the assumptions regarding=20 > the expected levels of ingress-egress aggregations is needed=20 > on the list?=20 >=20 > Towards that discussion, my personal view is that in the long=20 > range ignoring low levels of ingress-egress aggregation=20 > levels will severely limit the viability/usefulness of the=20 > technology. However, perhaps as an initial step it would be=20 > OK to assume moderate to high aggregation levels, as long as=20 > a clear path is visible on how to address low aggregations in=20 > the future within the scope of defined behaviors. But I=20 > think it is important to have a clear consensus on this point.=20 >=20 > Anna=20 >=20 > >=20 > > Lars > >=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Oct 19 10:20:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iisi6-0002w6-Kx; Fri, 19 Oct 2007 10:20:22 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Iisi4-0002qx-P1 for pcn-confirm+ok@megatron.ietf.org; Fri, 19 Oct 2007 10:20:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iisi3-0002pj-Ut for pcn@ietf.org; Fri, 19 Oct 2007 10:20:19 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iishx-00011y-PS for pcn@ietf.org; Fri, 19 Oct 2007 10:20:19 -0400 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l9JEJt714596; Fri, 19 Oct 2007 14:19:55 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Correction: RE: [PCN] Architecture draft - probing section & general updates. Date: Fri, 19 Oct 2007 10:19:52 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB646512B4E7B4@zcarhxm1.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Correction: RE: [PCN] Architecture draft - probing section & general updates. Thread-Index: AcgSUBT+aymtm9fVToiQGCN1HeZKlQAAC8jQAADCIFAAACiNoA== References: From: "Jozef Babiarz" To: "Anna Charny (acharny)" , "Lars Eggert" X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org I agree with Anna, and would like to add that the marking mechanism in core network needs to work equally well when ingress-egress aggregates passing through bottleneck router have small or large number of flows. Choosing marking approach that only works for one case is not that useful, at lest to me and my customers that are interested in PCN. On the probing issue, there are many (two+) methods currently defined and some already used in IP networks as well new methods that could be defined for possible use with PCN for admission control. I'm OK with deferring the selection of already defined protocol(s) or definition of new probing protocol until later date. However, I believe strongly that the architecture and the selection of PCN marking approach needs to take into consideration that probing may be part of some solutions/deployments and that details will be defined at some future time.=20 Regards, Joe email:babiarz@nortel.com Telephone:613-763-6098 -----Original Message----- From: Anna Charny (acharny) [mailto:acharny@cisco.com]=20 Sent: October 19, 2007 9:25 AM To: Anna Charny (acharny); Lars Eggert Cc: pcn@ietf.org Subject: Correction: RE: [PCN] Architecture draft - probing section & general updates. A typo in my previous message: I meant to say the charter does NOT restrict the low ingress-egress aggregation. Edited the appropriate sentense below... Anna > -----Original Message----- > From: Anna Charny (acharny)=20 > Sent: Friday, October 19, 2007 9:23 AM > To: 'Lars Eggert' > Cc: Hancock, Robert; philip.eardley@bt.com; pcn@ietf.org > Subject: RE: [PCN] Architecture draft - probing section &=20 > general updates. >=20 > Hi Lars, >=20 > On the low agfgregation point, please see below:=20 >=20 > > -----Original Message----- > > From: Lars Eggert [mailto:lars.eggert@nokia.com] > > Sent: Friday, October 19, 2007 8:58 AM > > To: Anna Charny (acharny) > > Cc: Hancock, Robert; philip.eardley@bt.com; pcn@ietf.org > > Subject: Re: [PCN] Architecture draft - probing section & general=20 > > updates. > >=20 > > On 2007-10-16, at 21:55, ext Anna Charny (acharny) wrote: > > > Yes, Robert's is a fair concern to which no obvious=20 > solution is in=20 > > > sight. Different equipment might use different algorithms=20 > and might=20 > > > use different fields for ECMP load-balancing under different=20 > > > circumstances. > > > IMHO this is a killer argument of why the use of probing for=20 > > > discovering the state of ECMP paths should not be=20 > considered within=20 > > > the scope of PCN WG. > >=20 > > Agreed. > >=20 > > > There remains a question of whether probing can/should be > > considerd to > > > probe the path regardless of the ECMP issue. I see most of > > its value > > > in flash crowd situations in combination with low ingress-egress=20 > > > agregation. > >=20 > > I note that scenarios with low aggregation aren't in scope of the > > charter: > >=20 > > The initial scope of the PCN WG is restricted by the following > > assumptions: > > ... > > (C) the number of flows across any potential aggregation=20 > bottleneck > > is sufficiently large for stateless, statistical mechanisms > > to be effective >=20 > Actually, I did not mean low aggregation *at the=20 > bottleneck*, which is what the charter seems to restrict. =20 > Rather I meant the case when the bottleneck has high=20 > aggregation, but traffic on that bottleneck comes from a=20 > large number of ingress-egress pairs, each having very low=20 > aggregation levels. I believe technically the charter does NOT=20 > put any explicit restrictions on the scope for ingress-egress=20 > aggregation.=20 >=20 > Perhaps the WG should consider whether it is reasonable to=20 > impose restrictions on the *ingress-egress* aggregation=20 > levels as well. An argument can be made that in practice a=20 > large number of ingress-egress pairs may only have a few=20 > flows, even when the bottleneck aggregations are large.=20 >=20 > The decision on whether low ingress-egress aggregation level=20 > is in scope seems to be important for choosing among the=20 > various approaches proposed to the WG, as some of them are=20 > substantially more sensitive to the low ingress-egress=20 > aggregations than others (e.g. single marking does not=20 > perform well at very low levels of aggregation, as we showed=20 > at the last meeting). =20 >=20 > Perhaps an explicit discussion on the assumptions regarding=20 > the expected levels of ingress-egress aggregations is needed=20 > on the list?=20 >=20 > Towards that discussion, my personal view is that in the long=20 > range ignoring low levels of ingress-egress aggregation=20 > levels will severely limit the viability/usefulness of the=20 > technology. However, perhaps as an initial step it would be=20 > OK to assume moderate to high aggregation levels, as long as=20 > a clear path is visible on how to address low aggregations in=20 > the future within the scope of defined behaviors. But I=20 > think it is important to have a clear consensus on this point.=20 >=20 > Anna=20 >=20 > >=20 > > Lars > >=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 Oct 19 10:21:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iisj9-0004KP-FU; Fri, 19 Oct 2007 10:21:27 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Iisj7-0004Jh-Vm for pcn-confirm+ok@megatron.ietf.org; Fri, 19 Oct 2007 10:21:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iisj6-0004Gz-VL for pcn@ietf.org; Fri, 19 Oct 2007 10:21:24 -0400 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 1Iisj0-00014l-Eo for pcn@ietf.org; Fri, 19 Oct 2007 10:21:24 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9JEKpfI016958; Fri, 19 Oct 2007 17:21:03 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Oct 2007 17:20:54 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh103.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Oct 2007 17:18:32 +0300 Received: from [172.21.39.202] (esdhcp039202.research.nokia.com [172.21.39.202]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9JEIUuP021731; Fri, 19 Oct 2007 17:18:31 +0300 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <675CA684-7FE8-4F51-B011-DD59BE1E29A1@nokia.com> From: Lars Eggert Subject: Re: [PCN] Architecture draft - probing section & general updates. Date: Fri, 19 Oct 2007 17:18:30 +0300 To: ext Anna Charny (acharny) X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 19 Oct 2007 14:18:32.0497 (UTC) FILETIME=[EDBC8210:01C8125A] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1660059407==" Errors-To: pcn-bounces@ietf.org --===============1660059407== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-55--252053564; protocol="application/pkcs7-signature" --Apple-Mail-55--252053564 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, On 2007-10-19, at 16:23, ext Anna Charny (acharny) wrote: > Actually, I did not mean low aggregation *at the bottleneck*, > which is > what the charter seems to restrict. Rather I meant the case when the > bottleneck has high aggregation, but traffic on that bottleneck comes > from a large number of ingress-egress pairs, each having very low > aggregation levels. I believe technically the charter does put any > explicit restrictions on the scope for ingress-egress aggregation. thanks for teasing these two issues apart. I had been under the assumption that one would come with the other, but you're correct that they can be unrelated. It was the intent of the charter to initially restrict PCN to scenarios with significant levels of multiplexing, so that simple, statistical measures are effective. So I'd argue that although the current charter text isn't explicit about ingress-egress-pair aggregation levels, it was written under the assumption that they'd be significant. That said, I do agree with you that it would be good to come to an explicit agreement on this within the WG. > Perhaps the WG should consider whether it is reasonable to impose > restrictions on the *ingress-egress* aggregation levels as well. An > argument can be made that in practice a large number of ingress-egress > pairs may only have a few flows, even when the bottleneck aggregations > are large. > > The decision on whether low ingress-egress aggregation level is in > scope > seems to be important for choosing among the various approaches > proposed > to the WG, as some of them are substantially more sensitive to the low > ingress-egress aggregations than others (e.g. single marking does not > perform well at very low levels of aggregation, as we showed at the > last > meeting). > > Perhaps an explicit discussion on the assumptions regarding the > expected > levels of ingress-egress aggregations is needed on the list? > > Towards that discussion, my personal view is that in the long range > ignoring low levels of ingress-egress aggregation levels will severely > limit the viability/usefulness of the technology. However, perhaps as > an initial step it would be OK to assume moderate to high aggregation > levels, as long as a clear path is visible on how to address low > aggregations in the future within the scope of defined behaviors. > But I > think it is important to have a clear consensus on this point. Agreed. I've stated my reasons for wanting PCN to focus on high-aggregation scenarios in previous emails. Let me add one additional argument: I see PCN as being complementary to traditional, hop-by-hop signaled QoS reservation mechanisms. These mechanisms already cover scenarios with low-aggregation levels well. They tend to break down for high traffic volumes, which is exactly where I'd expect PCN to be the most attractive. In other words, because using PCN in low-aggregation scenarios means that probing is required, with the already-discussed complexities, delays and overheads, traditional QoS mechanisms become attractive. Yes, signaled QoS mechanisms are more complex than PCN, but not much more complex than PCN with a fully-worked out probing mechanism. Additionally, signaled QoS setup results in a guarantee that a flow can be sustained, while even with probing, PCN will only results in an estimate on whether a flow can be sustained. Lars --Apple-Mail-55--252053564 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzEwMTkxNDE4MzFaMCMGCSqGSIb3DQEJBDEWBBTANpHwYk4YLLjf 9EQH1lRuX14vCTCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAOpHW3FI9e+0shBR9tC7Jnuhc9bTU0y8b98jxHw5owAjnK4JhMLqt TMoeBuIGmT7ySn1r8R63EAl0gfHChdvAWS+k0L8J3xqeStMEvwP1ul2tllqi28vt7CKr68ucWWdF e9T+uIt0GeBcZNTjxsO/avm1cRqdH9AQz1+91T+c3Z6L4viJRlGGguPC1mrJKqePmx7DVBrCDPyy PxuTweOfW0fwvWr145FcbNP7pWZ06BOEwryoArwSSHdIFX6Og/VTpshKd/YoVS3ppQGn5jh+JLdD NgE78wdONSMu0ZyMxYvJ8K26NNGgewDBm/1urmTWlUKel8ZfOFCquZymYMYEQQAAAAAAAA== --Apple-Mail-55--252053564-- --===============1660059407== 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 --===============1660059407==-- From pcn-bounces@ietf.org Fri Oct 19 10:49:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IitAT-0005yU-Ae; Fri, 19 Oct 2007 10:49:41 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IitAS-0005uQ-Eq for pcn-confirm+ok@megatron.ietf.org; Fri, 19 Oct 2007 10:49:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IitAR-0005r4-AN for pcn@ietf.org; Fri, 19 Oct 2007 10:49:39 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IitAQ-0006Vi-Cw for pcn@ietf.org; Fri, 19 Oct 2007 10:49:39 -0400 X-IronPort-AV: E=Sophos;i="4.21,301,1188802800"; d="scan'208";a="25308005" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 19 Oct 2007 07:49:35 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l9JEnZBI031630; Fri, 19 Oct 2007 07:49:35 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l9JEmXmb019396; Fri, 19 Oct 2007 14:49:35 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Oct 2007 10:49:24 -0400 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] Architecture draft - probing section & general updates. Date: Fri, 19 Oct 2007 10:49:22 -0400 Message-ID: In-Reply-To: <675CA684-7FE8-4F51-B011-DD59BE1E29A1@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Architecture draft - probing section & general updates. Thread-Index: AcgSW1AlagmbQOCGTY+NFlaP1Yyp9wAANMQg From: "Anna Charny (acharny)" To: "Lars Eggert" X-OriginalArrivalTime: 19 Oct 2007 14:49:24.0245 (UTC) FILETIME=[3D76D450:01C8125F] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15492.000 X-TM-AS-Result: No--28.880800-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5626; t=1192805375; x=1193669375; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=20=22Anna=20Charny=20(acharny)=22=20 |Subject:=20RE=3A=20[PCN]=20Architecture=20draft=20-=20probing=20section= 20&=20general=20updates. |Sender:=20; bh=kRPQ8buQsbQHmQXHTjic2ZG0QylF+vUGXSisq7ecdsc=; b=HsWJ13xs0aUv9eg8hwZHK9VCycyqRo0L9ohS7zxdNj49Kci5S4jqgmJDHgF69gQFPX3PfnGw V631YdW9XBza7bLpzx8RahmUTU9QtbNIF6k/I/cXFIjwYVlJ/hGhc2V/; Authentication-Results: sj-dkim-4; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Lars, I have a question and a point: 1) Question: =20 You say: > I see PCN as being complementary to traditional, hop-by-hop=20 > signaled QoS reservation mechanisms. These mechanisms already=20 > cover scenarios with low-aggregation levels well. They tend=20 > to break down for high traffic volumes, which is exactly=20 > where I'd expect PCN to be the most attractive.=20 =20 Why do you say that aggregate hop-by-hop reservation mechanisms tend to break at high traffic volumes?=20 2) Point: You say:=20 >In other=20 > words, because using PCN in low-aggregation scenarios means=20 > that probing is required, with the already-discussed=20 > complexities,=20 I would ask the question in two parts: - is it important for a mechanism to work well when there is a small number (but greater than 1) of ingress-egress flows for a large number of ingress-egress pairs. Note that this is not necessarily a question about probing, but that of performance of an algorithm on low ingress-egress aggregation levels (this is because once the first flow is accepted, it provides the necessary state for admission of future flows, and does it reasonably well at least for some of the proposed algorithms). - should the WG consider the case when expected number of flows on very large number of ingress-egress aggregates sharing a bottleneck has on the order of *one* flow. Note that this is the case when probing might be needed. Anna =20 > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@nokia.com]=20 > Sent: Friday, October 19, 2007 10:19 AM > To: Anna Charny (acharny) > Cc: Hancock, Robert; philip.eardley@bt.com; pcn@ietf.org > Subject: Re: [PCN] Architecture draft - probing section &=20 > general updates. >=20 > Hi, >=20 > On 2007-10-19, at 16:23, ext Anna Charny (acharny) wrote: > > Actually, I did not mean low aggregation *at the=20 > bottleneck*, which=20 > > is what the charter seems to restrict. Rather I meant the=20 > case when=20 > > the bottleneck has high aggregation, but traffic on that bottleneck=20 > > comes from a large number of ingress-egress pairs, each having very=20 > > low aggregation levels. I believe technically the charter does put=20 > > any explicit restrictions on the scope for ingress-egress=20 > aggregation. >=20 > thanks for teasing these two issues apart. I had been under=20 > the assumption that one would come with the other, but you're=20 > correct that they can be unrelated. >=20 > It was the intent of the charter to initially restrict PCN to=20 > scenarios with significant levels of multiplexing, so that=20 > simple, statistical measures are effective. So I'd argue that=20 > although the current charter text isn't explicit about=20 > ingress-egress-pair aggregation levels, it was written under=20 > the assumption that they'd be significant. >=20 > That said, I do agree with you that it would be good to come=20 > to an explicit agreement on this within the WG. >=20 > > Perhaps the WG should consider whether it is reasonable to impose=20 > > restrictions on the *ingress-egress* aggregation levels as=20 > well. An=20 > > argument can be made that in practice a large number of=20 > ingress-egress=20 > > pairs may only have a few flows, even when the bottleneck=20 > aggregations=20 > > are large. > > > > The decision on whether low ingress-egress aggregation level is in=20 > > scope seems to be important for choosing among the various=20 > approaches=20 > > proposed to the WG, as some of them are substantially more=20 > sensitive=20 > > to the low ingress-egress aggregations than others (e.g. single=20 > > marking does not perform well at very low levels of=20 > aggregation, as we=20 > > showed at the last meeting). > > > > Perhaps an explicit discussion on the assumptions regarding the=20 > > expected levels of ingress-egress aggregations is needed on=20 > the list? > > > > Towards that discussion, my personal view is that in the long range=20 > > ignoring low levels of ingress-egress aggregation levels=20 > will severely=20 > > limit the viability/usefulness of the technology. However,=20 > perhaps as=20 > > an initial step it would be OK to assume moderate to high=20 > aggregation=20 > > levels, as long as a clear path is visible on how to address low > > aggregations in the future within the scope of defined behaviors. =20 > > But I > > think it is important to have a clear consensus on this point. >=20 > Agreed. >=20 > I've stated my reasons for wanting PCN to focus on=20 > high-aggregation scenarios in previous emails. Let me add one=20 > additional argument: >=20 > I see PCN as being complementary to traditional, hop-by-hop=20 > signaled QoS reservation mechanisms. These mechanisms already=20 > cover scenarios with low-aggregation levels well. They tend=20 > to break down for high traffic volumes, which is exactly=20 > where I'd expect PCN to be the most attractive. In other=20 > words, because using PCN in low-aggregation scenarios means=20 > that probing is required, with the already-discussed=20 > complexities, delays and overheads, traditional QoS=20 > mechanisms become attractive. Yes, signaled QoS mechanisms=20 > are more complex than PCN, but not much more complex than PCN=20 > with a fully-worked out probing mechanism. Additionally,=20 > signaled QoS setup results in a guarantee that a flow can be=20 > sustained, while even with probing, PCN will only results in=20 > an estimate on whether a flow can be sustained. >=20 > Lars=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Oct 23 04:19:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkEz1-00034j-Fr; Tue, 23 Oct 2007 04:19:27 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IkEz0-00031b-Cg for pcn-confirm+ok@megatron.ietf.org; Tue, 23 Oct 2007 04:19:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkEyz-00030F-BL for pcn@ietf.org; Tue, 23 Oct 2007 04:19:25 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkEyt-0003CT-V5 for pcn@ietf.org; Tue, 23 Oct 2007 04:19:25 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Tue, 23 Oct 2007 10:19:06 +0200 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Oct 2007 10:19:05 +0200 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] Architecture draft - probing section & general updates. Date: Tue, 23 Oct 2007 10:19:05 +0200 Message-Id: <1B6169C658325341A3B8066E23919E1C0DE8FD@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC5CD@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Architecture draft - probing section & general updates. thread-index: AcgQFh3bpdXKC6/iTqGKgTMqojS39gFKBadg From: "Geib, Ruediger" To: X-OriginalArrivalTime: 23 Oct 2007 08:19:05.0926 (UTC) FILETIME=[60B5EE60:01C8154D] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Phil, I appreciate that probing is optional. I understand that to mean that standardisation allows to operate PCN within a domain without having to support any probing functionality. There may be operational conditions, when probing makes sense. This may be the case, if the number of multiplexed flows is at the lower bound of the range where statistical multiplexing can be applied on any link and the number of possible ingress to egress relations passing this link is big enough to lead to (pre-)congestion by admission of a single flow with a reasonable probability. I don't want to stop people from working on this issue, but I'd favour PCN to finish standards for an operational environment where the probability of a single admitted flow causing congestion on a link is extremly low.=20 Regards, Rudiger _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Oct 23 04:26:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkF5d-00016R-9M; Tue, 23 Oct 2007 04:26:17 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IkF5b-00016H-PN for pcn-confirm+ok@megatron.ietf.org; Tue, 23 Oct 2007 04:26:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkF5a-00015u-TC for pcn@ietf.org; Tue, 23 Oct 2007 04:26:14 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkF5V-0003TE-Vg for pcn@ietf.org; Tue, 23 Oct 2007 04:26:14 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Tue, 23 Oct 2007 10:26:08 +0200 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Oct 2007 10:26:08 +0200 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] Architecture draft - probing section & general updates. Date: Tue, 23 Oct 2007 10:26:08 +0200 Message-Id: <1B6169C658325341A3B8066E23919E1C0DE8FE@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Architecture draft - probing section & general updates. thread-index: AcgSW1AlagmbQOCGTY+NFlaP1Yyp9wAANMQgALxKnwA= From: "Geib, Ruediger" To: X-OriginalArrivalTime: 23 Oct 2007 08:26:08.0567 (UTC) FILETIME=[5C9FD470:01C8154E] X-Spam-Score: -1.0 (-) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Anna, could you re-write your point? I don't get the sense completely. Thanks, Rudiger | - should the WG consider the case when expected number of flows on |very large number of ingress-egress aggregates sharing a bottleneck has |on the order of *one* flow. Note that this is the case when probing |might be needed. _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Oct 23 09:38:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkJxh-0001LQ-EE; Tue, 23 Oct 2007 09:38:25 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IkJxf-0001Ig-QB for pcn-confirm+ok@megatron.ietf.org; Tue, 23 Oct 2007 09:38:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkJxe-0001I9-Vi for pcn@ietf.org; Tue, 23 Oct 2007 09:38:22 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkJxd-0000M0-Qc for pcn@ietf.org; Tue, 23 Oct 2007 09:38:22 -0400 X-IronPort-AV: E=Sophos;i="4.21,317,1188792000"; d="scan'208";a="135453512" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 23 Oct 2007 09:38:21 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9NDcLcW013644; Tue, 23 Oct 2007 09:38:21 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l9NDc8kF027714; Tue, 23 Oct 2007 13:38:21 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Oct 2007 09:38:16 -0400 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] Architecture draft - probing section & general updates. Date: Tue, 23 Oct 2007 09:38:15 -0400 Message-ID: In-Reply-To: <1B6169C658325341A3B8066E23919E1C0DE8FE@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Architecture draft - probing section & general updates. Thread-Index: AcgSW1AlagmbQOCGTY+NFlaP1Yyp9wAANMQgALxKnwAACpgUoA== From: "Anna Charny (acharny)" To: "Geib, Ruediger" X-OriginalArrivalTime: 23 Oct 2007 13:38:16.0404 (UTC) FILETIME=[F748F940:01C81579] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15500.002 X-TM-AS-Result: No--1.997800-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1736; t=1193146701; x=1194010701; 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]=20Architecture=20draft=20-=20probing=20section= 20&=20general=20updates. |Sender:=20 |To:=20=22Geib,=20Ruediger=22=20; bh=nDAzEp2CHPmEGxltnAOwnhvfKAMfOOYdHcTEykOnsUQ=; b=jbP5Jg4MAoyGgSVxKpInc05UeZxGuvngiONl45d1c83yJCsjjJgUtvOgQn2Epb3YmldSFI+C bdjwSfulAfFZMzf69UlndqZoLW1wdQ7NQb+/PMPr2qCeQc5nMgsBXxKK; Authentication-Results: rtp-dkim-1; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Ruediger, I meant roughly the following. Suppose many ingress-egress aggregates have on the average 1 flow. If you have just one flow per ingress-egress aggregate, when this flow arrives and is the only one active in its ingress-egress pair, and if no=20 probing of any kind is used, then effectively there is no admission control for this aggregate. If many such aggregates share a bottleneck, then effectively all these ingress-egress aggregates have to be admitted regardless of the state of the bottleneck. In the extreme, if all ingress-egress aggregates sharing a bottleneck consist of one flow, then this bottleneck effectively does not have any admission control. In such situations probing might be quite useful, as it will enable admission control.=20 Of course one does not have to require that *all* ingress-egress aggregates sharing a bottleneck have just one flow to have a similar problem - just enough of them on the average to take a substantial share of the bottleneck bandwidth. Does it make sense? Anna=20 > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]=20 > Sent: Tuesday, October 23, 2007 4:26 AM > To: Anna Charny (acharny) > Cc: pcn@ietf.org > Subject: RE: [PCN] Architecture draft - probing section &=20 > general updates. >=20 > Anna, >=20 > could you re-write your point? I don't get the sense completely. >=20 > Thanks, >=20 > Rudiger >=20 >=20 > | - should the WG consider the case when expected number of=20 > flows on=20 > |very large number of ingress-egress aggregates sharing a=20 > bottleneck has=20 > |on the order of *one* flow. Note that this is the case when probing=20 > |might be needed. >=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Oct 23 10:19:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkKb8-0001s7-21; Tue, 23 Oct 2007 10:19:10 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IkKb6-0001n8-TB for pcn-confirm+ok@megatron.ietf.org; Tue, 23 Oct 2007 10:19:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkKb5-0001kS-Hg for pcn@ietf.org; Tue, 23 Oct 2007 10:19:07 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkKaz-0002F4-6F for pcn@ietf.org; Tue, 23 Oct 2007 10:19:07 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Tue, 23 Oct 2007 16:18:53 +0200 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Oct 2007 16:18:52 +0200 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] Architecture draft - probing section & general updates. Date: Tue, 23 Oct 2007 16:18:52 +0200 Message-Id: <1B6169C658325341A3B8066E23919E1C0DE90F@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Architecture draft - probing section & general updates. thread-index: AcgSW1AlagmbQOCGTY+NFlaP1Yyp9wAANMQgALxKnwAACpgUoAABOnrg From: "Geib, Ruediger" To: X-OriginalArrivalTime: 23 Oct 2007 14:18:52.0523 (UTC) FILETIME=[A3533BB0:01C8157F] X-Spam-Score: -1.0 (-) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Anna, thanks, I understand your explanation.=20 Regards, Rudiger |-----Original Message----- |From: Anna Charny (acharny) [mailto:acharny@cisco.com] |Sent: Tuesday, October 23, 2007 3:38 PM |To: Geib, Rudiger |Cc: pcn@ietf.org |Subject: RE: [PCN] Architecture draft - probing section & general |updates. | | |Hi Ruediger, | |I meant roughly the following. Suppose many ingress-egress aggregates |have on the average 1 flow. If you have just one flow per |ingress-egress aggregate, when this flow arrives and is the only one |active in its ingress-egress pair, and if no probing of any kind is=20 |used, then effectively there is no admission control for this=20 |aggregate. If many such aggregates share a bottleneck, then=20 |effectively all these ingress-egress aggregates have to be admitted |regardless of the state of the bottleneck. In the extreme, if all |ingress-egress aggregates sharing a bottleneck consist of one flow,=20 |then this bottleneck effectively does not have any admission control. |In such situations probing might be quite useful, as it will enable |admission control.=20 | |Of course one does not have to require that *all* ingress-egress |aggregates sharing a bottleneck have just one flow to have a similar |problem - just enough of them on the average to take a substantial=20 |share of the bottleneck bandwidth. | |Does it make sense? |Anna=20 | |> -----Original Message----- |> From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]=20 |> Sent: Tuesday, October 23, 2007 4:26 AM |> To: Anna Charny (acharny) |> Cc: pcn@ietf.org |> Subject: RE: [PCN] Architecture draft - probing section &=20 |> general updates. |>=20 |> Anna, |>=20 |> could you re-write your point? I don't get the sense completely. |>=20 |> Thanks, |>=20 |> Rudiger |>=20 |>=20 |> | - should the WG consider the case when expected number of=20 |> flows on=20 |> |very large number of ingress-egress aggregates sharing a=20 |> bottleneck has=20 |> |on the order of *one* flow. Note that this is the case=20 |when probing=20 |> |might be needed. |>=20 | _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Oct 23 10:46:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkL1I-00063S-K0; Tue, 23 Oct 2007 10:46:12 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IkL1H-00061k-Lj for pcn-confirm+ok@megatron.ietf.org; Tue, 23 Oct 2007 10:46:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkL1G-000607-Hi for pcn@ietf.org; Tue, 23 Oct 2007 10:46:10 -0400 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 1IkL1A-0003gY-5Y for pcn@ietf.org; Tue, 23 Oct 2007 10:46:10 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9NEjTui022509; Tue, 23 Oct 2007 17:46:00 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Oct 2007 17:45:52 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Oct 2007 17:17:28 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Oct 2007 17:17:24 +0300 Received: from [172.21.34.120] (esdhcp034120.research.nokia.com [172.21.34.120]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9NEHNXQ024692; Tue, 23 Oct 2007 17:17:24 +0300 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <732CE53D-C2B8-48D6-8757-EB1839E072CA@nokia.com> From: Lars Eggert Subject: Re: [PCN] Architecture draft - probing section & general updates. Date: Tue, 23 Oct 2007 17:17:19 +0300 To: ext Anna Charny (acharny) X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 23 Oct 2007 14:17:24.0980 (UTC) FILETIME=[6F253B40:01C8157F] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: pcn@ietf.org, "Geib, Ruediger" X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1073949739==" Errors-To: pcn-bounces@ietf.org --===============1073949739== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-14-93474989; protocol="application/pkcs7-signature" --Apple-Mail-14-93474989 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-10-23, at 16:38, ext Anna Charny (acharny) wrote: > I meant roughly the following. Suppose many ingress-egress aggregates > have on the average 1 flow. If you have just one flow per > ingress-egress aggregate, when this flow arrives and is the only one > active in its ingress-egress pair, and if no > probing of any kind is used, then effectively there is no admission > control for this aggregate. If many such aggregates share a > bottleneck, > then effectively all these ingress-egress aggregates have to be > admitted > regardless of the state of the bottleneck. In the extreme, if all > ingress-egress aggregates sharing a bottleneck consist of one flow, > then > this bottleneck effectively does not have any admission control. In > such situations probing might be quite useful, as it will enable > admission control. To me, this looks like an awfully unlikely corner case. Do we really need to spend effort to make sure admission control can happen in this case? Can't we simply leave it to the flow termination procedure to kick in and remove the excess load, if such a case should really occur? Lars --Apple-Mail-14-93474989 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzEwMjMxNDE3MjBaMCMGCSqGSIb3DQEJBDEWBBQgL03yXn9Qd1dr lEtoVhvzw1q9SDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEANUJCBBgnEV8jZkO1CKRE/6HtJtelUAKyqwh6DCxKaELjpWcuKOOn cnURCd4dLrAGPUCWweX/XYOfPRPCVkn9r+ZfJVdGBngWnKSuR8nQXIPPsJnFBE8+OxVYxLSml/uc DH7egfRW/UHNYV4M19K858FPfHtMo66BUlbNXtCt2RXzka/X1tOvI+0M8O+1/TW3SZwX+E33RVDc yKgYh9AZ4/KXo4uSSkEKw8ipb45mbgitv3EiBE9phi5OOdJU+pK5xZRIiEqXolkH/NM748fxYjpG i/n/uowrZsTzge8cHU3uPQZ22OlPAtdsUMxpSpAtKCJdhcukv5moZBtXUV/swgAAAAAAAA== --Apple-Mail-14-93474989-- --===============1073949739== 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 --===============1073949739==-- From pcn-bounces@ietf.org Tue Oct 23 12:15:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkMPh-0000XO-4X; Tue, 23 Oct 2007 12:15:29 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IkMPe-0000T9-AB for pcn-confirm+ok@megatron.ietf.org; Tue, 23 Oct 2007 12:15:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkMPd-0000O9-0X for pcn@ietf.org; Tue, 23 Oct 2007 12:15:25 -0400 Received: from wrzx28.rz.uni-wuerzburg.de ([132.187.3.28] helo=mailrelay.rz.uni-wuerzburg.de) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkMPc-0005ME-KX for pcn@ietf.org; Tue, 23 Oct 2007 12:15:24 -0400 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id C3E5DC0B5 for ; Tue, 23 Oct 2007 18:15:21 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id B6033C0BA for ; Tue, 23 Oct 2007 18:15:21 +0200 (CEST) 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 A2F2FC0B5 for ; Tue, 23 Oct 2007 18:15:21 +0200 (CEST) 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 l9NGFLh03771 for ; Tue, 23 Oct 2007 18:15:21 +0200 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 70C986F591 for ; Tue, 23 Oct 2007 18:08:06 +0200 (CEST) Message-ID: <471E1C5C.5020502@informatik.uni-wuerzburg.de> Date: Tue, 23 Oct 2007 18:07:56 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) 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: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [PCN] RSVP and ECMP X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi, I've got a question regarding RSVP. PATH messages need to be carried over the same path as subsequent data packets. How is this achieved in the presence of ECMP routing? In theory, PATH messages can take a different route than data packets if the load balancer takes arbitrary parts of the header(s) to calculate a suitable hash value, which decides which route the packet will take. This issue seems to be related to the problem of how to make sure that PCN probe messages take the same path as subsequent PCN data packets, provided that they have the same source and destination ports and addresses. I am interested in how this problem is solved in practice or whether it is intentionally avoided. 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 Tue Oct 23 12:22:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkMWN-0005RS-I3; Tue, 23 Oct 2007 12:22:23 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IkMWL-0005RG-RO for pcn-confirm+ok@megatron.ietf.org; Tue, 23 Oct 2007 12:22:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkMWK-0005Q3-Oi for pcn@ietf.org; Tue, 23 Oct 2007 12:22:20 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkMWC-000087-IX for pcn@ietf.org; Tue, 23 Oct 2007 12:22:18 -0400 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 l9NGJ1716385; Tue, 23 Oct 2007 16:19:02 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Architecture draft - probing section & general updates. Date: Tue, 23 Oct 2007 12:21:43 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB646512C6F7D0@zcarhxm1.corp.nortel.com> In-Reply-To: <1B6169C658325341A3B8066E23919E1C0DE8FD@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Architecture draft - probing section & general updates. Thread-Index: AcgQFh3bpdXKC6/iTqGKgTMqojS39gFKBadgABQhwRA= References: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC5CD@E03MVZ1-UKDY.domain1.systemhost.net> <1B6169C658325341A3B8066E23919E1C0DE8FD@S4DE8PSAANK.mitte.t-com.de> From: "Jozef Babiarz" To: "Geib, Ruediger" , X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Ruediger, the issue is not addition of one more flow into the link that is experiencing (pre-)congestion level for admission but potentially hundreds of new ingress-egress aggregates that have not been established passing through the link.=20 Regards, Joe email:babiarz@nortel.com Telephone:613-763-6098 -----Original Message----- From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]=20 Sent: October 23, 2007 4:19 AM To: philip.eardley@bt.com Cc: pcn@ietf.org Subject: RE: [PCN] Architecture draft - probing section & general updates. Phil, I appreciate that probing is optional. I understand that to mean that standardisation allows to operate PCN within a domain without having to support any probing functionality. There may be operational conditions, when probing makes sense. This may be the case, if the number of multiplexed flows is at the lower bound of the range where statistical multiplexing can be applied on any link and the number of possible ingress to egress relations passing this link is big enough to lead to (pre-)congestion by admission of a single flow with a reasonable probability. I don't want to stop people from working on this issue, but I'd favour PCN to finish standards for an operational environment where the probability of a single admitted flow causing congestion on a link is extremly low.=20 Regards, Rudiger _______________________________________________ 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 Oct 23 12:46:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkMsU-0003aT-KO; Tue, 23 Oct 2007 12:45:14 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IkMsS-0003Yb-GJ for pcn-confirm+ok@megatron.ietf.org; Tue, 23 Oct 2007 12:45:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkMsR-0003Xs-KU for pcn@ietf.org; Tue, 23 Oct 2007 12:45:11 -0400 Received: from services110.cs.uwaterloo.ca ([129.97.152.166]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkMsR-0006UT-9W for pcn@ietf.org; Tue, 23 Oct 2007 12:45:11 -0400 Received: from [129.97.34.33] (kalli.uwaterloo.ca [129.97.34.33]) (authenticated bits=0) by services110.cs.uwaterloo.ca (8.13.8/8.13.8) with ESMTP id l9NGj8K2023363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 23 Oct 2007 12:45:09 -0400 (EDT) Message-ID: <471E2514.8060905@cs.uwaterloo.ca> Date: Tue, 23 Oct 2007 12:45:08 -0400 From: Martin Karsten User-Agent: Thunderbird 1.5.0.12 (X11/20070719) MIME-Version: 1.0 To: pcn@ietf.org Subject: Re: [PCN] RSVP and ECMP References: <471E1C5C.5020502@informatik.uni-wuerzburg.de> In-Reply-To: <471E1C5C.5020502@informatik.uni-wuerzburg.de> X-Enigmail-Version: 0.94.3.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Miltered: at minos with ID 471E2514.002 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on localhost X-Virus-Status: Clean X-UUID: f08e6c5d-b4af-47ce-af14-d0f22b5ef8ae X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org I'm not sure what's done in reality (if at all), but RSVP PATH messages have the 'router alert' flag set, so in theory they are processed differently from a regular IP packet anyway. Greetings, Martin Michael Menth wrote: > Hi, > > I've got a question regarding RSVP. PATH messages need to be carried > over the same path as subsequent data packets. How is this achieved in > the presence of ECMP routing? In theory, PATH messages can take a > different route than data packets if the load balancer takes arbitrary > parts of the header(s) to calculate a suitable hash value, which decides > which route the packet will take. > > This issue seems to be related to the problem of how to make sure that > PCN probe messages take the same path as subsequent PCN data packets, > provided that they have the same source and destination ports and > addresses. > > I am interested in how this problem is solved in practice or whether it > is intentionally avoided. > > Regards, > > Michael > _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Oct 23 12:51:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkMyt-00051y-4D; Tue, 23 Oct 2007 12:51:51 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IkMyr-00051j-Cc for pcn-confirm+ok@megatron.ietf.org; Tue, 23 Oct 2007 12:51:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkMyp-00051S-Mt for pcn@ietf.org; Tue, 23 Oct 2007 12:51:48 -0400 Received: from wrzx28.rz.uni-wuerzburg.de ([132.187.3.28] helo=mailrelay.rz.uni-wuerzburg.de) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkMyo-0006j6-QC for pcn@ietf.org; Tue, 23 Oct 2007 12:51:47 -0400 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 48561BF4A; Tue, 23 Oct 2007 18:51:46 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 3AD75C04E; Tue, 23 Oct 2007 18:51:46 +0200 (CEST) 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 06BEABF4A; Tue, 23 Oct 2007 18:51:44 +0200 (CEST) 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 l9NGpih04059; Tue, 23 Oct 2007 18:51:44 +0200 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 08C8D6F591; Tue, 23 Oct 2007 18:44:28 +0200 (CEST) Message-ID: <471E24E2.90403@informatik.uni-wuerzburg.de> Date: Tue, 23 Oct 2007 18:44:18 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Martin Karsten Subject: Re: [PCN] RSVP and ECMP References: <471E1C5C.5020502@informatik.uni-wuerzburg.de> <471E2514.8060905@cs.uwaterloo.ca> In-Reply-To: <471E2514.8060905@cs.uwaterloo.ca> 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: 0a7aa2e6e558383d84476dc338324fab 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: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Martin, yes you are right, but this is a different issue. The question is: how is it achieved that RSVP PATH messages are routed on the same path as subsequent data packets in the presence of ECMP? Regards, Michael Martin Karsten wrote: > I'm not sure what's done in reality (if at all), but RSVP PATH messages > have the 'router alert' flag set, so in theory they are processed > differently from a regular IP packet anyway. > > Greetings, > Martin > > Michael Menth wrote: > >> Hi, >> >> I've got a question regarding RSVP. PATH messages need to be carried >> over the same path as subsequent data packets. How is this achieved in >> the presence of ECMP routing? In theory, PATH messages can take a >> different route than data packets if the load balancer takes arbitrary >> parts of the header(s) to calculate a suitable hash value, which decides >> which route the packet will take. >> >> This issue seems to be related to the problem of how to make sure that >> PCN probe messages take the same path as subsequent PCN data packets, >> provided that they have the same source and destination ports and >> addresses. >> >> I am interested in how this problem is solved in practice or whether it >> is intentionally avoided. >> >> Regards, >> >> Michael >> >> > > > > _______________________________________________ > 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 Tue Oct 23 13:51:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkNum-0007Qd-Uh; Tue, 23 Oct 2007 13:51:40 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IkNul-0007Pc-HN for pcn-confirm+ok@megatron.ietf.org; Tue, 23 Oct 2007 13:51:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkNuk-0007PO-OT for pcn@ietf.org; Tue, 23 Oct 2007 13:51:38 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkNu3-0004bd-SV for pcn@ietf.org; Tue, 23 Oct 2007 13:51:38 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 23 Oct 2007 10:50:55 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9NHotJq017320; Tue, 23 Oct 2007 10:50:55 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9NHojxJ022611; Tue, 23 Oct 2007 17:50:55 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Oct 2007 10:50:51 -0700 Received: from [10.32.241.67] ([10.32.241.67]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Oct 2007 10:50:50 -0700 In-Reply-To: <471E1C5C.5020502@informatik.uni-wuerzburg.de> References: <471E1C5C.5020502@informatik.uni-wuerzburg.de> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6C20D78B-36AE-4D88-8F7A-20F4D4A512A4@cisco.com> Content-Transfer-Encoding: 7bit From: Bruce Davie Subject: Re: [PCN] RSVP and ECMP Date: Tue, 23 Oct 2007 13:50:42 -0400 To: menth@informatik.uni-wuerzburg.de X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 23 Oct 2007 17:50:50.0928 (UTC) FILETIME=[4015D300:01C8159D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2197; t=1193161855; x=1194025855; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=bdavie@cisco.com; z=From:=20Bruce=20Davie=20 |Subject:=20Re=3A=20[PCN]=20RSVP=20and=20ECMP |Sender:=20; bh=F9r1LQj/EYtzF3uzrMqinG2xS1HAxkh806HqwcyBoIY=; b=r+Ik+/PNx9OnaSi+pGBohObN5MDXzpjUybsuHIb6FJErRcbBudTzjiGxqBWyDwF5ovAhUTBQ 8F2OeqrwclDl+wiXEdeVZ1oYD6q4psxMlRUm6IjC3tv/EwhQ5JiHS4fk; Authentication-Results: sj-dkim-2; header.From=bdavie@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Michael, RSVP tries to forward the Path exactly the same way that it would forward the data. Since Path messages are processed outside of the fast path, it is possible for the router to look at anything that is in the path message, including source addr, dest addr, and port numbers, and figure out where a data packet that had those values in its IP header would get forwarded. It sends the Path message out that interface. In practice, this takes care of the vast majority of ECMP algorithms. This approach is implemented today. If ECMP was using something from the IP or higher layer header that was not in the Path message, then a problem would arise. So, practically speaking, if the probe messages have the same addresses and ports as the data, they should get correct ECMP treatment. Or at least, fare no worse than RSVP. Bruce On Oct 23, 2007, at 12:07 PM, Michael Menth wrote: > Hi, > > I've got a question regarding RSVP. PATH messages need to be > carried over the same path as subsequent data packets. How is this > achieved in the presence of ECMP routing? In theory, PATH messages > can take a different route than data packets if the load balancer > takes arbitrary parts of the header(s) to calculate a suitable hash > value, which decides which route the packet will take. > > This issue seems to be related to the problem of how to make sure > that PCN probe messages take the same path as subsequent PCN data > packets, provided that they have the same source and destination > ports and addresses. > > I am interested in how this problem is solved in practice or > whether it is intentionally avoided. > > 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 Wed Oct 24 03:04:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkaHT-00053m-9g; Wed, 24 Oct 2007 03:03:55 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IkaHR-00053g-Qd for pcn-confirm+ok@megatron.ietf.org; Wed, 24 Oct 2007 03:03:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkaHN-0004tg-2k for pcn@ietf.org; Wed, 24 Oct 2007 03:03:49 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkaHG-0000ni-MN for pcn@ietf.org; Wed, 24 Oct 2007 03:03:49 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Wed, 24 Oct 2007 09:03:36 +0200 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Oct 2007 09:03:35 +0200 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] Architecture draft - probing section & general updates. Date: Wed, 24 Oct 2007 09:03:35 +0200 Message-Id: <1B6169C658325341A3B8066E23919E1C0DE91D@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <9671A92C3C8B5744BC97F855F7CB646512C6F7D0@zcarhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Architecture draft - probing section & general updates. thread-index: AcgQFh3bpdXKC6/iTqGKgTMqojS39gFKBadgABQhwRAAHsa+UA== From: "Geib, Ruediger" To: X-OriginalArrivalTime: 24 Oct 2007 07:03:35.0897 (UTC) FILETIME=[FF041C90:01C8160B] X-Spam-Score: -1.0 (-) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Joe, my perception is, that probing may be useful, once there is=20 pre-congestion. In a situation without a single admitted=20 flow between an ingress and an egress, if neither ingress=20 node nor egress node have any indication of pre-congestion=20 on any of the links crossed by the PCN flows passing through=20 them, there's with high probability no need to probe,=20 I'd assume. I don't do simulations and would like to invite those simulating to come up with cases where this assumption=20 is wrong. I'd further propose to collect information from providers=20 on the probability of the event you describe.=20 Regards,=20 Rudiger |-----Original Message----- |From: Jozef Babiarz [mailto:babiarz@nortel.com] |Sent: Tuesday, October 23, 2007 6:22 PM |To: Geib, Rudiger; philip.eardley@bt.com |Cc: pcn@ietf.org |Subject: RE: [PCN] Architecture draft - probing section & general |updates. | | |Ruediger, the issue is not addition of one more flow into the link that |is experiencing (pre-)congestion level for admission but potentially |hundreds of new ingress-egress aggregates that have not been=20 |established |passing through the link.=20 | |Regards, Joe |email:babiarz@nortel.com |Telephone:613-763-6098 | |-----Original Message----- |From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]=20 |Sent: October 23, 2007 4:19 AM |To: philip.eardley@bt.com |Cc: pcn@ietf.org |Subject: RE: [PCN] Architecture draft - probing section & general |updates. | |Phil, | |I appreciate that probing is optional. I understand that to mean that |standardisation allows to operate PCN within a domain without having to |support any probing functionality. | |There may be operational conditions, when probing makes sense. This may |be the case, if the number of multiplexed flows is at the=20 |lower bound of |the range where statistical multiplexing can be applied on any link and |the number of possible ingress to egress relations passing this link is |big enough to lead to (pre-)congestion by admission of a single flow |with a reasonable probability. I don't want to stop people from working |on this issue, but I'd favour PCN to finish standards for an=20 |operational |environment where the probability of a single admitted flow causing |congestion on a link is extremly low.=20 | |Regards, | |Rudiger | | |_______________________________________________ |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 Oct 24 06:24:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkdOk-0001lo-IR; Wed, 24 Oct 2007 06:23:38 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IkdOi-0001kk-Hf for pcn-confirm+ok@megatron.ietf.org; Wed, 24 Oct 2007 06:23:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkdOh-0001k7-Mn for pcn@ietf.org; Wed, 24 Oct 2007 06:23:35 -0400 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkdOh-0008CI-9b for pcn@ietf.org; Wed, 24 Oct 2007 06:23:35 -0400 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.63]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Oct 2007 11:23:34 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 24 Oct 2007 11:23:34 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC5F4@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PCN & tunnelling Thread-Index: AcgWJ+54M2I8eYc4QJu/kWUfuySz/Q== From: To: X-OriginalArrivalTime: 24 Oct 2007 10:23:34.0455 (UTC) FILETIME=[EEB6C470:01C81627] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1 Subject: [PCN] PCN & tunnelling X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1232073198==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1232073198== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C81627.EE9357BD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C81627.EE9357BD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I was chatting with Bob about section 5.8 tunnelling. We've realised there's the following nasty case which we hadn't thought about. The scenario is when a tunnel starts inside a PCN-domain and finishes outside it.=20 =20 First we follow what happens when the current text is followed. Imagine that the pkt is PCN-marked by some PCN-node before the tunnel start node. On encapsulation the PCN-mark is copied onto the outer header. Hence the PCN-egress-node 'sees' the PCN-mark as normal - this is ok. The PCN-egress-node clears the marking in the (outer) header and forwards the pkt into the next domain. The pkt is decapsulated at the tunnel end point. But the decapsulated pkt is already PCN-marked. Potential problems: [1] if it's decapsulated in a non-PCN-domain, then the pkt may confuse nodes in this domain [depending on what encoding is used for a PCN-mark] ; [2] if it's decapsulated in a PCN-domain, then the pkt is PCN-marked [which might lead this PCN-domain to terminate or block a flow unnecessarily]. =20 The problem arises because the PCN-egress-node clears PCN-marking on the outer header but not on the inner header. (This is a new problem compared with ECN & tunnelling.)=20 =20 Possible solution: if the pkt is PCN-marked, then the tunnel start node checks whether the tunnel egress is inside or outside the PCN-domain - if it's outside, then it clears the PCN-marking on the inner header (effectively it does this on behalf of the PCN-egress-node). (Also, the PCN-mark is copied onto the outer header, as the current text says.) =20 Thoughts? =20 Thanks, Phil/ =20 ------_=_NextPart_001_01C81627.EE9357BD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I was chatting with Bob about section 5.8 tunnelling. = We’ve realised there’s the following nasty case which we hadn’t = thought about. The scenario is when a tunnel starts inside a PCN-domain and = finishes outside it.

 

First we follow what happens when the current text is followed. = Imagine that the pkt is PCN-marked by some PCN-node before the tunnel start = node. On encapsulation the PCN-mark is copied onto the outer header. Hence the PCN-egress-node = ‘sees’ the PCN-mark as normal – this is ok. The PCN-egress-node clears = the marking in the (outer) header and forwards the pkt into the next domain. The pkt = is decapsulated at the tunnel end point. But the decapsulated pkt is = already PCN-marked. Potential problems: [1] if it’s decapsulated in a non-PCN-domain, then the pkt may confuse nodes in this domain [depending = on what encoding is used for a PCN-mark] ; [2] if it’s decapsulated = in a PCN-domain, then the pkt is PCN-marked [which might lead this PCN-domain to = terminate or block a flow unnecessarily].

 

The problem arises because the PCN-egress-node clears = PCN-marking on the outer header but not on the inner header. (This is a new problem = compared with ECN & tunnelling.)

 

Possible solution: if the pkt is PCN-marked, then the tunnel = start node checks whether the tunnel egress is inside or outside the PCN-domain - = if it’s outside, then it clears the PCN-marking on the inner header (effectively = it does this on behalf of the PCN-egress-node). (Also, the PCN-mark is = copied onto the outer header, as the current text says.)

 

Thoughts?

 

Thanks,

Phil/  

=00 ------_=_NextPart_001_01C81627.EE9357BD-- --===============1232073198== 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 --===============1232073198==-- From pcn-bounces@ietf.org Wed Oct 24 06:57:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkdvD-0002wq-6V; Wed, 24 Oct 2007 06:57:11 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Ikdv7-0002wB-Rk for pcn-confirm+ok@megatron.ietf.org; Wed, 24 Oct 2007 06:57:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikdv7-0002w3-EC for pcn@ietf.org; Wed, 24 Oct 2007 06:57:05 -0400 Received: from wrzx28.rz.uni-wuerzburg.de ([132.187.3.28] helo=mailrelay.rz.uni-wuerzburg.de) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ikdv6-0000cb-P4 for pcn@ietf.org; Wed, 24 Oct 2007 06:57:05 -0400 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 1F34CD477; Wed, 24 Oct 2007 12:57:04 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 11067D479; Wed, 24 Oct 2007 12:57:04 +0200 (CEST) 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 D4DF1D477; Wed, 24 Oct 2007 12:57:02 +0200 (CEST) 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 l9OAv2h10229; Wed, 24 Oct 2007 12:57:02 +0200 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id A30226F591; Wed, 24 Oct 2007 12:49:43 +0200 (CEST) Message-ID: <471F233A.4060203@informatik.uni-wuerzburg.de> Date: Wed, 24 Oct 2007 12:49:30 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: philip.eardley@bt.com Subject: Re: [PCN] PCN & tunnelling References: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC5F4@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC5F4@E03MVZ1-UKDY.domain1.systemhost.net> Content-Type: text/plain; charset=windows-1252; format=flowed X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac 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: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Phil, philip.eardley@bt.com wrote: > > Hi, > > I was chatting with Bob about section 5.8 tunnelling. We=92ve realised=20 > there=92s the following nasty case which we hadn=92t thought about. The= =20 > scenario is when a tunnel starts inside a PCN-domain and finishes=20 > outside it. > > First we follow what happens when the current text is followed.=20 > Imagine that the pkt is PCN-marked by some PCN-node before the tunnel=20 > start node. On encapsulation the PCN-mark is copied onto the outer=20 > header. Hence the PCN-egress-node =91sees=92 the PCN-mark as normal =96= this=20 > is ok. The PCN-egress-node clears the marking in the (outer) header=20 > and forwards the pkt into the next domain. The pkt is decapsulated at=20 > the tunnel end point. But the decapsulated pkt is already PCN-marked.=20 > Potential problems: [1] if it=92s decapsulated in a non-PCN-domain, the= n=20 > the pkt may confuse nodes in this domain [depending on what encoding=20 > is used for a PCN-mark] ; [2] if it=92s decapsulated in a PCN-domain,=20 > then the pkt is PCN-marked [which might lead this PCN-domain to=20 > terminate or block a flow unnecessarily]. > > The problem arises because the PCN-egress-node clears PCN-marking on=20 > the outer header but not on the inner header. (This is a new problem=20 > compared with ECN & tunnelling.) > > Possible solution: if the pkt is PCN-marked, then the tunnel start=20 > node checks whether the tunnel egress is inside or outside the=20 > PCN-domain - if it=92s outside, then it clears the PCN-marking on the=20 > inner header (effectively it does this on behalf of the=20 > PCN-egress-node). (Also, the PCN-mark is copied onto the outer header,=20 > as the current text says.) > > Thoughts? > At first sight I find this solution quite simple and good. There are many other open issues regarding how PCN should behave in the=20 case of tunneling. In general, I think multi-domain issues are not yet=20 well understood and tunneling can create very nasty side effects. http://www1.ietf.org/mail-archive/web/pcn/current/msg00687.html I find it is important to record these caveats linked with tunneling and=20 interdomain aspects, but I don't think that PCN must be bullet-proof for=20 everything, at least these problems should not prevent simple solutions=20 in the near future. Regards, Michael > Thanks, > > Phil/ > > -----------------------------------------------------------------------= - > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn > =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 Wed Oct 24 07:10:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ike7v-0003Se-6A; Wed, 24 Oct 2007 07:10:19 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Ike7t-0003N9-MW for pcn-confirm+ok@megatron.ietf.org; Wed, 24 Oct 2007 07:10:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ike7t-0003N1-46 for pcn@ietf.org; Wed, 24 Oct 2007 07:10:17 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ike7s-0000x0-Hf for pcn@ietf.org; Wed, 24 Oct 2007 07:10:17 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Wed, 24 Oct 2007 13:10:11 +0200 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Oct 2007 13:10:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PCN] PCN & tunnelling Date: Wed, 24 Oct 2007 13:10:10 +0200 Message-Id: <1B6169C658325341A3B8066E23919E1C0DE924@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC5F4@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PCN & tunnelling thread-index: AcgWJ+54M2I8eYc4QJu/kWUfuySz/QABQXZQ From: "Geib, Ruediger" To: X-OriginalArrivalTime: 24 Oct 2007 11:10:11.0053 (UTC) FILETIME=[719DC1D0:01C8162E] X-Spam-Score: 0.0 (/) X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1616903898==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1616903898== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8162E.715B829F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8162E.715B829F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Phil, =20 I guess this is a general DiffServ issue too. In case [2] you assume the same DSCP to be used by the tunnel end point PCN domain as at the tunnel entry. This assumption may not hold, if the set DSCP is used for another service class or unused at the end point.=20 =20 I had a brief glance on RFC2983, "Differentiated Services and Tunnels". Downpropagation of outer IP header DSCP/PCN settings may be a fairly good recommendation. =20 Regards, =20 Rudiger -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: Wednesday, October 24, 2007 12:24 PM To: pcn@ietf.org Subject: [PCN] PCN & tunnelling Hi, =20 I was chatting with Bob about section 5.8 tunnelling. We've realised there's the following nasty case which we hadn't thought about. The scenario is when a tunnel starts inside a PCN-domain and finishes outside it.=20 =20 First we follow what happens when the current text is followed. Imagine that the pkt is PCN-marked by some PCN-node before the tunnel start node. On encapsulation the PCN-mark is copied onto the outer header. Hence the PCN-egress-node 'sees' the PCN-mark as normal - this is ok. The PCN-egress-node clears the marking in the (outer) header and forwards the pkt into the next domain. The pkt is decapsulated at the tunnel end point. But the decapsulated pkt is already PCN-marked. Potential problems: [1] if it's decapsulated in a non-PCN-domain, then the pkt may confuse nodes in this domain [depending on what encoding is used for a PCN-mark] ; [2] if it's decapsulated in a PCN-domain, then the pkt is PCN-marked [which might lead this PCN-domain to terminate or block a flow unnecessarily]. =20 The problem arises because the PCN-egress-node clears PCN-marking on the outer header but not on the inner header. (This is a new problem compared with ECN & tunnelling.)=20 =20 Possible solution: if the pkt is PCN-marked, then the tunnel start node checks whether the tunnel egress is inside or outside the PCN-domain - if it's outside, then it clears the PCN-marking on the inner header (effectively it does this on behalf of the PCN-egress-node). (Also, the PCN-mark is copied onto the outer header, as the current text says.) =20 Thoughts? =20 Thanks, Phil/ =20 ------_=_NextPart_001_01C8162E.715B829F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Phil,
 
I=20 guess this is a general DiffServ issue too. In case [2] you assume the = same DSCP=20 to be used by the tunnel end point PCN domain as at the tunnel = entry. This=20 assumption may not hold, if the set DSCP is used for another = service class=20 or unused at the end point.
 
I had=20 a brief glance on RFC2983,=20 "Differentiated Services and Tunnels". Downpropagation of outer IP = header=20 DSCP/PCN settings may be a fairly good = recommendation.
 
Regards,
 
Rudiger
-----Original Message-----
From: = philip.eardley@bt.com=20 [mailto:philip.eardley@bt.com]
Sent: Wednesday, October 24, = 2007=20 12:24 PM
To: pcn@ietf.org
Subject: [PCN] PCN & = tunnelling

Hi,

 

I was chatting with Bob about section 5.8 = tunnelling.=20 We’ve realised there’s the following nasty case which we = hadn’t thought about.=20 The scenario is when a tunnel starts inside a PCN-domain and finishes = outside=20 it.

 

First we follow what happens when the = current text is=20 followed. Imagine that the pkt is PCN-marked by some PCN-node before = the=20 tunnel start node. On encapsulation the PCN-mark is copied onto the = outer=20 header. Hence the PCN-egress-node ‘sees’ the PCN-mark as = normal – this is ok.=20 The PCN-egress-node clears the marking in the (outer) header and = forwards the=20 pkt into the next domain. The pkt is decapsulated at the tunnel end = point. But=20 the decapsulated pkt is already PCN-marked. Potential problems: [1] if = it’s=20 decapsulated in a non-PCN-domain, then the pkt may confuse nodes in = this=20 domain [depending on what encoding is used for a PCN-mark] ; [2] if = it’s=20 decapsulated in a PCN-domain, then the pkt is PCN-marked [which might = lead=20 this PCN-domain to terminate or block a flow = unnecessarily].

 

The problem arises because the = PCN-egress-node clears=20 PCN-marking on the outer header but not on the inner header. (This is = a new=20 problem compared with ECN & tunnelling.)

 

Possible solution: if the pkt is PCN-marked, = then the=20 tunnel start node checks whether the tunnel egress is inside or = outside the=20 PCN-domain - if it’s outside, then it clears the PCN-marking on = the inner=20 header (effectively it does this on behalf of the PCN-egress-node). = (Also, the=20 PCN-mark is copied onto the outer header, as the current text=20 says.)

 

Thoughts?

 

Thanks,

Phil/=20  

------_=_NextPart_001_01C8162E.715B829F-- --===============1616903898== 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 --===============1616903898==-- From pcn-bounces@ietf.org Wed Oct 24 07:58:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikes2-0003m6-MF; Wed, 24 Oct 2007 07:57:58 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Ikes1-0003lD-4m for pcn-confirm+ok@megatron.ietf.org; Wed, 24 Oct 2007 07:57:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikes0-0003jb-Lm for pcn@ietf.org; Wed, 24 Oct 2007 07:57:56 -0400 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ikes0-000281-1k for pcn@ietf.org; Wed, 24 Oct 2007 07:57:56 -0400 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.63]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Oct 2007 12:57:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 24 Oct 2007 12:57:54 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC5F5@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: more PCN comments on architecture draft Thread-Index: AcgQ2a1Cf6XPDSt3S2Ga7nGalCXZBAAhI+vgATR7s6A= From: To: X-OriginalArrivalTime: 24 Oct 2007 11:57:55.0181 (UTC) FILETIME=[1CC501D0:01C81635] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6379955759c38e2371a49573a0932fc7 Subject: [PCN] more PCN comments on architecture draft X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0674150626==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0674150626== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C81635.1C83C7FF" This is a multi-part message in MIME format. ------_=_NextPart_001_01C81635.1C83C7FF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bob gave me some hand-written comments on the architecture draft =3D> = here are the changes I suggest. I think they're non-controversial (possible exception: the terminology tweak, since terminology is always controversial!). I think they're most self-explanatory, but please shout if they need explanation /discussion, or indeed are wrong. Thanks, phil =20 =20 - Benefits: clarified the "Admission control is resilient" bullet by adding the last phrase to the following sentence: - Benefits: clarified that the objective is also to stop PCN-packets being significantly delayed (current text only mentions not dropping pkts) - Benefits: added a new bullet: - added another deployment scenario: - MPLS deployment model: corrected reference to MPLS-TE to say MPLS - Terminology: PCN-domain: the current definition ("a PCN-capable DiffServ domain; a contiguous set of PCN-enabled DiffServ nodes.") doesn't work very well (eg adjacent PCN-domains consist of a contiguous set of PCN-nodes). Suggesting the following definition: - S3.2: assumption 2: added the following 1st sentence as a clarification. - S4: clarified that PCN-interior-node functionality applies for each outgoing interface, and added clarification: - S4 (near end): when there's traffic less important than PCN, now says: (-00 version said "may" rather than "should". I think this better reflects the advice in the EF rfc (although since the architecture draft is Informational and nothing is in capital letters, it's a bit hair-splitting). - S5: changed a few places to talk about the PCN functionality being done on an interface (-00 version says 'link' and 'interface' seems clearer) - S5.2: deleted erroneous mention of service level agreement - S5.8: Tunnelling: see comment earlier today on list. Add ref to [ecn-mpls]. "effective elimination of ECMP as a load balancing mechanism" is too strong (I'm trying alternative wording - or else I may end up just deleting the phrase] - S5.5: Probing: new section as on the list.=20 - S5.7 addressing: in the case where traffic is always tunnelled across the PCN-domain, add a note that he PCN-ingress-node needs to know the address of the PCN-egress-node - S6: open issues - made it clearer that: I also edited a couple of sentences that were close to solution space.=20 - S6: flash crowds: phrased more accurately (replaced the poor phrases "speed of reaction" & "handling request faster than vulnerability period") - S6: added another open issue: Silent at start: after a successful admission request the source may wait some time before sending data (eg waiting for the called party to answer). Then the risk is that, in some circumstances, PCN's measurements underestimate what the pre-congestion level will be when the source does start sending data. ------_=_NextPart_001_01C81635.1C83C7FF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Bob gave me some hand-written comments on the architecture draft = =3D> here are the changes I suggest. I think they’re non-controversial (possible exception: the terminology tweak, since terminology is always controversial!). I think they’re most self-explanatory, but please = shout if they need explanation /discussion, or indeed are = wrong.

Thanks,

phil

 

 

-        = ;  Benefits: clarified the “Admission control is = resilient” bullet by adding the last phrase to the following sentence: <PCN's = QoS is decoupled from the routing system; hence in general admitted flows can = survive capacity, routing or topology changes without additional signalling, and they = don't have to be told (or learn) about such changes.>

-        = ;  Benefits: clarified that the objective is also to stop PCN-packets being significantly delayed (current text only mentions not dropping pkts)

-        = ;  Benefits: added a new bullet: <Provisioning of the = network is decoupled from the process of adding new customers. By contrast, with = the DiffServ architecture [RFC2475] the operator has to run the provisioning process each time a new customer is added to check that the Service = Level Agreement can be fulfilled.  >

-        = ;  added another deployment scenario: <If the operator = runs both the access network and the core network, one deployment scenario is that = only the core network uses PCN admission control but per microflow policing = is done at the ingress to the access network and not at the PCN-ingress-node. = Note: to aid readability, the rest of this draft assumes that policing is done by = the PCN-ingress-nodes.>

-        = ;  MPLS deployment model: corrected reference to MPLS-TE to = say MPLS

-     Terminology: PCN-domain: the current definition (“a PCN-capable DiffServ domain; a contiguous set of PCN-enabled DiffServ nodes.”) doesn’t work very well (eg = adjacent PCN-domains consist of a contiguous set of PCN-nodes). Suggesting the = following definition: <PCN-domain: a PCN-capable domain; a contiguous set of = PCN-enabled nodes that perform DiffServ scheduling; the compete set of PCN-nodes = whose PCN-marking can in principle influence decisions about flow admission = and termination for the PCN-domain, including the PCN-egress-nodes which = measure these PCN-marks.>

-     S3.2: assumption 2: added the = following 1st sentence as a clarification. <We assume that any variation of source = bit rate is independent of the level of = pre-congestion.>

-        = ;  S4: clarified that PCN-interior-node functionality applies = for each outgoing interface, and added clarification: <The functionality = is also done by PCN-ingress-nodes for their outgoing interfaces (ie those = 'inside' the PCN-domain).>

-        = ;  S4 (near end): when there’s traffic less important = than PCN, now says: <a PCN-node should dedicate some capacity to lower = priority traffic so that it isn't starved.> (-00 version said = “may” rather than “should”. I think this better reflects the = advice in the EF rfc (although since the architecture draft is Informational and = nothing is in capital letters, it’s a bit hair-splitting).

-        = ;  S5: changed a few places to talk about the PCN = functionality being done on an interface (-00 version says ‘link’ and ‘interface’ seems clearer)

-        = ;  S5.2: deleted erroneous mention of service level = agreement

-     S5.8: Tunnelling: see comment earlier = today on list. Add ref to [ecn-mpls]. “effective elimination of ECMP as = a load balancing mechanism” is too strong (I’m trying alternative = wording – or else I may end up just deleting the phrase]

-        = ;  S5.5: Probing: new section as on the list.

-        = ;  S5.7 addressing: in the case where traffic is always = tunnelled across the PCN-domain, add a note that he PCN-ingress-node needs to know = the address of the PCN-egress-node

-        = ;  S6: open issues - made it clearer that: <NOTE: = Potential solutions are out of scope for this document.> I also edited a couple = of sentences that were close to solution space.

-     S6: flash crowds: phrased more = accurately (replaced the poor phrases “speed of reaction” & “handling = request faster than vulnerability period”)

-        = ;  S6: added another open issue: Silent at start: after a = successful admission request the source may wait some time before sending data (eg = waiting for the called party to answer). Then the risk is that, in some = circumstances, PCN's measurements underestimate what the pre-congestion level will be = when the source does start sending data.

=00 ------_=_NextPart_001_01C81635.1C83C7FF-- --===============0674150626== 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 --===============0674150626==-- From pcn-bounces@ietf.org Wed Oct 24 09:30:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkgJF-00076I-V3; Wed, 24 Oct 2007 09:30:09 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IkgJE-00075I-7t for pcn-confirm+ok@megatron.ietf.org; Wed, 24 Oct 2007 09:30:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkgJD-00074z-Ri for pcn@ietf.org; Wed, 24 Oct 2007 09:30:07 -0400 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 1IkgJC-0005mq-BN for pcn@ietf.org; Wed, 24 Oct 2007 09:30:07 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 24 Oct 2007 06:30:05 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l9ODU5fG029704; Wed, 24 Oct 2007 06:30:05 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9ODU3x9015210; Wed, 24 Oct 2007 13:30:04 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Oct 2007 09:29:55 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PCN] PCN & tunnelling Date: Wed, 24 Oct 2007 09:29:53 -0400 Message-ID: In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC5F4@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN & tunnelling Thread-Index: AcgWJ+54M2I8eYc4QJu/kWUfuySz/QAGbMXg From: "Anna Charny (acharny)" To: , X-OriginalArrivalTime: 24 Oct 2007 13:29:55.0174 (UTC) FILETIME=[F6F11860:01C81641] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15502.002 X-TM-AS-Result: No--23.672600-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8912; t=1193232605; x=1194096605; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=20=22Anna=20Charny=20(acharny)=22=20 |Subject:=20RE=3A=20[PCN]=20PCN=20&=20tunnelling |Sender:=20; bh=WdYszEm6eKzHSPeclwQuZlP/r9K3ciTGMZD0GEPckpU=; b=hKbIwqzBmUnds2VsgRgJxa2FKgiumBD2QopvgaDU92GqHBNvgf2BmPAI4kXPa6i4+rwlHeam eZaxFzJNzJwkIqki83iGnKNzpKZnp3t0DinoREHcrepGQXkkaH/jCMND; Authentication-Results: sj-dkim-4; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0345042589==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0345042589== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C81641.F6AD60C6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C81641.F6AD60C6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Phil, =20 Question: what would be the mechanism for knowing whether the egress of the tunnel is in the PCN domain or not? Are we assuming that a node somehow advertises its PCN capability? I do not think we ever explicitly assumed that? =20 Anna=20 ________________________________ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: Wednesday, October 24, 2007 6:24 AM To: pcn@ietf.org Subject: [PCN] PCN & tunnelling =09 =09 Hi, =20 I was chatting with Bob about section 5.8 tunnelling. We've realised there's the following nasty case which we hadn't thought about. The scenario is when a tunnel starts inside a PCN-domain and finishes outside it.=20 =20 First we follow what happens when the current text is followed. Imagine that the pkt is PCN-marked by some PCN-node before the tunnel start node. On encapsulation the PCN-mark is copied onto the outer header. Hence the PCN-egress-node 'sees' the PCN-mark as normal - this is ok. The PCN-egress-node clears the marking in the (outer) header and forwards the pkt into the next domain. The pkt is decapsulated at the tunnel end point. But the decapsulated pkt is already PCN-marked. Potential problems: [1] if it's decapsulated in a non-PCN-domain, then the pkt may confuse nodes in this domain [depending on what encoding is used for a PCN-mark] ; [2] if it's decapsulated in a PCN-domain, then the pkt is PCN-marked [which might lead this PCN-domain to terminate or block a flow unnecessarily]. =20 The problem arises because the PCN-egress-node clears PCN-marking on the outer header but not on the inner header. (This is a new problem compared with ECN & tunnelling.)=20 =20 Possible solution: if the pkt is PCN-marked, then the tunnel start node checks whether the tunnel egress is inside or outside the PCN-domain - if it's outside, then it clears the PCN-marking on the inner header (effectively it does this on behalf of the PCN-egress-node). (Also, the PCN-mark is copied onto the outer header, as the current text says.) =20 Thoughts? =20 Thanks, Phil/ =20 ------_=_NextPart_001_01C81641.F6AD60C6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Phil,
 
Question: what would be the mechanism for = knowing whether=20 the egress of the tunnel is in the PCN domain or not?  Are we = assuming that=20 a node somehow advertises its PCN capability?  I do not think we = ever=20 explicitly assumed that?
 
Anna

From: philip.eardley@bt.com=20 [mailto:philip.eardley@bt.com]
Sent: Wednesday, October 24, = 2007=20 6:24 AM
To: pcn@ietf.org
Subject: [PCN] PCN &=20 tunnelling

Hi,

 

I was chatting with Bob about section 5.8 = tunnelling.=20 We’ve realised there’s the following nasty case which we = hadn’t thought about.=20 The scenario is when a tunnel starts inside a PCN-domain and finishes = outside=20 it.

 

First we follow what happens when the = current text is=20 followed. Imagine that the pkt is PCN-marked by some PCN-node before = the=20 tunnel start node. On encapsulation the PCN-mark is copied onto the = outer=20 header. Hence the PCN-egress-node ‘sees’ the PCN-mark as = normal – this is ok.=20 The PCN-egress-node clears the marking in the (outer) header and = forwards the=20 pkt into the next domain. The pkt is decapsulated at the tunnel end = point. But=20 the decapsulated pkt is already PCN-marked. Potential problems: [1] if = it’s=20 decapsulated in a non-PCN-domain, then the pkt may confuse nodes in = this=20 domain [depending on what encoding is used for a PCN-mark] ; [2] if = it’s=20 decapsulated in a PCN-domain, then the pkt is PCN-marked [which might = lead=20 this PCN-domain to terminate or block a flow = unnecessarily].

 

The problem arises because the = PCN-egress-node clears=20 PCN-marking on the outer header but not on the inner header. (This is = a new=20 problem compared with ECN & tunnelling.)

 

Possible solution: if the pkt is PCN-marked, = then the=20 tunnel start node checks whether the tunnel egress is inside or = outside the=20 PCN-domain - if it’s outside, then it clears the PCN-marking on = the inner=20 header (effectively it does this on behalf of the PCN-egress-node). = (Also, the=20 PCN-mark is copied onto the outer header, as the current text=20 says.)

 

Thoughts?

 

Thanks,

Phil/=20  

------_=_NextPart_001_01C81641.F6AD60C6-- --===============0345042589== 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 --===============0345042589==-- From pcn-bounces@ietf.org Wed Oct 24 09:54:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkggY-0003L4-0g; Wed, 24 Oct 2007 09:54:14 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IkggW-0003Ji-Qx for pcn-confirm+ok@megatron.ietf.org; Wed, 24 Oct 2007 09:54:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkggW-0003JZ-Gm for pcn@ietf.org; Wed, 24 Oct 2007 09:54:12 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkggV-0006p8-7Z for pcn@ietf.org; Wed, 24 Oct 2007 09:54:12 -0400 X-IronPort-AV: E=Sophos;i="4.21,324,1188792000"; d="scan'208";a="74682084" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 24 Oct 2007 09:54:09 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9ODs9aD019891; Wed, 24 Oct 2007 09:54:09 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l9ODrokj019483; Wed, 24 Oct 2007 13:54:09 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Oct 2007 09:54:06 -0400 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] Architecture draft - probing section & general updates. Date: Wed, 24 Oct 2007 09:54:05 -0400 Message-ID: In-Reply-To: <1B6169C658325341A3B8066E23919E1C0DE91D@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Architecture draft - probing section & general updates. Thread-Index: AcgQFh3bpdXKC6/iTqGKgTMqojS39gFKBadgABQhwRAAHsa+UAAOGxPA From: "Anna Charny (acharny)" To: "Geib, Ruediger" , X-OriginalArrivalTime: 24 Oct 2007 13:54:06.0930 (UTC) FILETIME=[58417B20:01C81645] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15502.002 X-TM-AS-Result: No--22.027300-8.000000-2 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4821; t=1193234049; x=1194098049; 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]=20Architecture=20draft=20-=20probing=20section= 20&=20general=20updates. |Sender:=20 |To:=20=22Geib, =20Ruediger=22=20, =20; bh=b5EiFgRJ8WfkK3ZM4o15xdOnatv1TW1Dma/5f0Clzmw=; b=gOMKWUal6JM1yCJW1FJs7vDYgymKKD+ym+NB8MMiobjmWm1rb/NEQzrltH5+pyIFycnjzeCL p6RPh+nC5Rz9AQFMz6ZmkCrNuIR9LQ9caEnQ8KSBl/50gh1U2q2R/dmB; Authentication-Results: rtp-dkim-1; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi all, I think it boils down to a set of questions below. If anyone has any direct data regarding real-time traffic from today's Diffserv networks (or any futuire projections) that can help answer those questions, itr would help resolve the probing discussion. 1) is it a common occurrence in todays Diffserv networks (say using EF to support real-time traffic) that a large number of ingress-egress EF aggregates have just 1-2 flows? [I do not have direct data but from many incidental pieces of information I think the answer may be yes] 2) Is it reasonable to assume that when video becomes widespread, many ingress-egress aggregates might have just 1 video flow? [I do not see why this cannot be the case] 3) Even if many ingress-egress aggregates are small, is it a common occurrence that on a bottleneck link inside the network a large portion of the bottleneck bandwidth is taken by those small ingress-egress aggregates?=20 [It seems a more expected case is when the bottleneck is shared by large and small aggregates, and the large aggregates take a fair amount of bandwidth. It this case, under "normal circumstances" when the demand on the bottleneck does not drastically exceed the configured admission rate, admission control will likely resolve the pre-congestion at the expence of the large aggregates.] 4) Are there realistic circumstances (flash crowds or massive failures lasting for some time?) when the load on the bottleneck of small aggregates alone might cause substantial overload? (and if so, should we attempt to address these cases for admission or just rely on termination? Anna=20 =20 > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]=20 > Sent: Wednesday, October 24, 2007 3:04 AM > To: babiarz@nortel.com > Cc: pcn@ietf.org > Subject: RE: [PCN] Architecture draft - probing section &=20 > general updates. >=20 > Joe, >=20 > my perception is, that probing may be useful, once there is=20 > pre-congestion. In a situation without a single admitted flow=20 > between an ingress and an egress, if neither ingress node nor=20 > egress node have any indication of pre-congestion on any of=20 > the links crossed by the PCN flows passing through them,=20 > there's with high probability no need to probe, I'd assume. I=20 > don't do simulations and would like to invite those=20 > simulating to come up with cases where this assumption is wrong. >=20 > I'd further propose to collect information from providers on=20 > the probability of the event you describe.=20 >=20 > Regards,=20 >=20 > Rudiger >=20 > |-----Original Message----- > |From: Jozef Babiarz [mailto:babiarz@nortel.com] > |Sent: Tuesday, October 23, 2007 6:22 PM > |To: Geib, Rudiger; philip.eardley@bt.com > |Cc: pcn@ietf.org > |Subject: RE: [PCN] Architecture draft - probing section & general=20 > |updates. > | > | > |Ruediger, the issue is not addition of one more flow into=20 > the link that=20 > |is experiencing (pre-)congestion level for admission but potentially=20 > |hundreds of new ingress-egress aggregates that have not been=20 > |established passing through the link. > | > |Regards, Joe > |email:babiarz@nortel.com > |Telephone:613-763-6098 > | > |-----Original Message----- > |From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > |Sent: October 23, 2007 4:19 AM > |To: philip.eardley@bt.com > |Cc: pcn@ietf.org > |Subject: RE: [PCN] Architecture draft - probing section & general=20 > |updates. > | > |Phil, > | > |I appreciate that probing is optional. I understand that to=20 > mean that=20 > |standardisation allows to operate PCN within a domain=20 > without having to=20 > |support any probing functionality. > | > |There may be operational conditions, when probing makes=20 > sense. This may=20 > |be the case, if the number of multiplexed flows is at the=20 > lower bound=20 > |of the range where statistical multiplexing can be applied=20 > on any link=20 > |and the number of possible ingress to egress relations passing this=20 > |link is big enough to lead to (pre-)congestion by admission=20 > of a single=20 > |flow with a reasonable probability. I don't want to stop people from=20 > |working on this issue, but I'd favour PCN to finish standards for an=20 > |operational environment where the probability of a single=20 > admitted flow=20 > |causing congestion on a link is extremly low. > | > |Regards, > | > |Rudiger > | > | > |_______________________________________________ > |PCN mailing list > |PCN@ietf.org > |https://www1.ietf.org/mailman/listinfo/pcn > | >=20 >=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn >=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Oct 24 10:20:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikh4w-000327-Hn; Wed, 24 Oct 2007 10:19:26 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Ikh4v-00031y-Ec for pcn-confirm+ok@megatron.ietf.org; Wed, 24 Oct 2007 10:19:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikh4u-00031q-Rq for pcn@ietf.org; Wed, 24 Oct 2007 10:19:24 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ikh4u-0006IS-8w for pcn@ietf.org; Wed, 24 Oct 2007 10:19:24 -0400 X-IronPort-AV: E=Sophos;i="4.21,324,1188792000"; d="scan'208";a="135567213" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 24 Oct 2007 10:19:25 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9OEJOa5013162; Wed, 24 Oct 2007 10:19:24 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l9OEJ1kX029958; Wed, 24 Oct 2007 14:19:23 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Oct 2007 10:19:09 -0400 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] RSVP and ECMP Date: Wed, 24 Oct 2007 10:19:08 -0400 Message-ID: In-Reply-To: <6C20D78B-36AE-4D88-8F7A-20F4D4A512A4@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] RSVP and ECMP Thread-Index: AcgVndml+QY8RZibTBGng5cn3JfQdAAp7ZnQ From: "Anna Charny (acharny)" To: "Bruce Davie (bdavie)" , X-OriginalArrivalTime: 24 Oct 2007 14:19:09.0453 (UTC) FILETIME=[D7D44BD0:01C81648] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15502.002 X-TM-AS-Result: No--39.705300-8.000000-2 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4268; t=1193235564; x=1194099564; 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]=20RSVP=20and=20ECMP |Sender:=20 |To:=20=22Bruce=20Davie=20(bdavie)=22=20, =0A=20=20=20=2 0=20=20=20=20; bh=ubJ3Iewwax2GFl1zMeb+CNu2fQ9ImejcrXCAjDZuF4M=; b=NpE0DtbFvSMMrKvLjIaA3i4ldQpiZsXwHQ9dGRQ1IWhf9qWnqVJPAKMNl6TK3Rhy0U4dV/hn gp8gyA2NvDPEW0EwwaGAdILGAt0LuS2hLWdrX46EJeYDv+tHc4JjZ6P9; 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: c83ccb5cc10e751496398f1233ca9c3a Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi all, Bringing this in the context of using RSVP messages for probing. =20 If internal pcn nodes are doing the "standard" load-balancing (i.e. use ip src & dst or the 5-tuple) info from the packet header), then it seems at least two deployment scenarios are "safe" in terms of sending the RSVP messages along the same path as the data: 1) a(per flow) intserv-over-diffserv situation - in this case per-flow rsvp messages will have the appropriate fields used by ecmp the same as the corresponding data packets of this flow 2) an aggregate rsvp reservation coupled with tunnelling. (If tunneling is not used, then if the core does load balancing based on 5-tuple, different flows inside the reservation might be forwarded on different paths) Not so safe cases arise in general when ecmp looks deeper into the packet than the granularity of RSVP message (i.e the "flow" granularity as seen by RSVP is different than the "flow" granularity as seem by ecmp; e.g. when RSVP is used on an mpls tunnel, but the ecmp looks at the 5-tuple). One way to move forward (if we wanted to use RSVP as probes) is to explicitly restrict the deployment scenarios when this is not an issue and make explicit assumptions on how ecmp algorithms work in those deployment scenarios. =20 On second thought making such assumptions may not be too bad, because when they are violated, it seems that the system will then behave no worse than if probing is not used at all. =20 Thoughts? Anna=20 > -----Original Message----- > From: Bruce Davie (bdavie)=20 > Sent: Tuesday, October 23, 2007 1:51 PM > To: menth@informatik.uni-wuerzburg.de > Cc: pcn@ietf.org > Subject: Re: [PCN] RSVP and ECMP >=20 > Michael, > RSVP tries to forward the Path exactly the same way that it=20 > would forward the data. Since Path messages are processed=20 > outside of the fast path, it is possible for the router to=20 > look at anything that is in the path message, including=20 > source addr, dest addr, and port numbers, and figure out=20 > where a data packet that had those values in its IP header=20 > would get forwarded. It sends the Path message out that=20 > interface. In practice, this takes care of the vast majority=20 > of ECMP algorithms. This approach is implemented today. >=20 > If ECMP was using something from the IP or higher layer=20 > header that was not in the Path message, then a problem would arise. >=20 > So, practically speaking, if the probe messages have the=20 > same addresses and ports as the data, they should get correct=20 > ECMP treatment. Or at least, fare no worse than RSVP. >=20 > Bruce >=20 > On Oct 23, 2007, at 12:07 PM, Michael Menth wrote: >=20 > > Hi, > > > > I've got a question regarding RSVP. PATH messages need to=20 > be carried=20 > > over the same path as subsequent data packets. How is this=20 > achieved in=20 > > the presence of ECMP routing? In theory, PATH messages can take a=20 > > different route than data packets if the load balancer=20 > takes arbitrary=20 > > parts of the header(s) to calculate a suitable hash value, which=20 > > decides which route the packet will take. > > > > This issue seems to be related to the problem of how to=20 > make sure that=20 > > PCN probe messages take the same path as subsequent PCN=20 > data packets,=20 > > provided that they have the same source and destination ports and=20 > > addresses. > > > > I am interested in how this problem is solved in practice=20 > or whether=20 > > it is intentionally avoided. > > > > Regards, > > > > Michael > > > > -- > > Dr. Michael Menth, Assistant Professor University of Wuerzburg,=20 > > Institute of Computer Science Am Hubland, D-97074=20 > Wuerzburg, Germany,=20 > > room B206 > > phone: (+49)-931/888-6644, fax: (+49)-931/888-6632=20 > > 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 >=20 >=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn >=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Oct 24 10:42:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkhQm-0005No-Av; Wed, 24 Oct 2007 10:42:00 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IkhQl-0005Nh-4k for pcn-confirm+ok@megatron.ietf.org; Wed, 24 Oct 2007 10:41:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkhQk-0005NW-RC for pcn@ietf.org; Wed, 24 Oct 2007 10:41:58 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkhQY-0000Is-Pg for pcn@ietf.org; Wed, 24 Oct 2007 10:41:55 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Wed, 24 Oct 2007 16:41:21 +0200 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Oct 2007 16:41:21 +0200 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] Architecture draft - probing section & general updates. Date: Wed, 24 Oct 2007 16:41:20 +0200 Message-Id: <1B6169C658325341A3B8066E23919E1C0DE927@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Architecture draft - probing section & general updates. thread-index: AcgQFh3bpdXKC6/iTqGKgTMqojS39gFKBadgABQhwRAAHsa+UAAOGxPAAAGwngA= From: "Geib, Ruediger" To: X-OriginalArrivalTime: 24 Oct 2007 14:41:21.0266 (UTC) FILETIME=[F1A6D520:01C8164B] X-Spam-Score: -1.0 (-) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Anna, one more remark on your question 4) would be, that Deutsche Telekom=20 - to the extent I'm aware of it - does not plan her network=20 to provide QoS also during massive failures or flash crowds. To=20 the best of my knowledge, also consumer organisations rank our=20 IP network as the best or at least one of the best in Germany.=20 It is dimensioned to cope with probable failures and forseeable=20 traffic developments. I doubt that any carrier acting in a highly=20 competitive market, possibly regulated in some parts, intends to=20 invest heavily into his network to provide QoS also under very=20 exceptional operational conditions. Especially, if a solution=20 working under normal operational conditions was significantly=20 cheaper or faster and easier to deploy. Regards, Rudiger |-----Original Message----- |From: Anna Charny (acharny) [mailto:acharny@cisco.com] |Sent: Wednesday, October 24, 2007 3:54 PM |To: Geib, Rudiger; babiarz@nortel.com |Cc: pcn@ietf.org |Subject: RE: [PCN] Architecture draft - probing section & general |updates. | | |Hi all, | |I think it boils down to a set of questions below. If anyone has any |direct data regarding real-time traffic from today's Diffserv networks |(or any futuire projections) that can help answer those questions, itr |would help resolve the probing discussion. | |1) is it a common occurrence in todays Diffserv networks (say using EF |to support real-time traffic) that a large number of ingress-egress EF |aggregates have just 1-2 flows? [I do not have direct data but from |many incidental pieces of information I think the answer may be yes] | |2) Is it reasonable to assume that when video becomes widespread, many |ingress-egress aggregates might have just 1 video flow? [I do not see |why this cannot be the case] | |3) Even if many ingress-egress aggregates are small, is it a common |occurrence that on a bottleneck link inside the network a large portion |of the bottleneck bandwidth is taken by those small ingress-egress |aggregates?=20 |[It seems a more expected case is when the bottleneck is=20 |shared by large |and small aggregates, and the large aggregates take a fair amount of |bandwidth. It this case, under "normal circumstances" when the=20 |demand on |the bottleneck does not drastically exceed the configured admission |rate, admission control will likely resolve the pre-congestion at the |expence of the large aggregates.] | |4) Are there realistic circumstances (flash crowds or massive failures |lasting for some time?) when the load on the bottleneck of small |aggregates alone might cause substantial overload? (and if so, should |we attempt to address these cases for admission or just rely on |termination? | |Anna=20 | |=20 | |> -----Original Message----- |> From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]=20 |> Sent: Wednesday, October 24, 2007 3:04 AM |> To: babiarz@nortel.com |> Cc: pcn@ietf.org |> Subject: RE: [PCN] Architecture draft - probing section &=20 |> general updates. |>=20 |> Joe, |>=20 |> my perception is, that probing may be useful, once there is=20 |> pre-congestion. In a situation without a single admitted flow=20 |> between an ingress and an egress, if neither ingress node nor=20 |> egress node have any indication of pre-congestion on any of=20 |> the links crossed by the PCN flows passing through them,=20 |> there's with high probability no need to probe, I'd assume. I=20 |> don't do simulations and would like to invite those=20 |> simulating to come up with cases where this assumption is wrong. |>=20 |> I'd further propose to collect information from providers on=20 |> the probability of the event you describe.=20 |>=20 |> Regards,=20 |>=20 |> Rudiger |>=20 |> |-----Original Message----- |> |From: Jozef Babiarz [mailto:babiarz@nortel.com] |> |Sent: Tuesday, October 23, 2007 6:22 PM |> |To: Geib, Rudiger; philip.eardley@bt.com |> |Cc: pcn@ietf.org |> |Subject: RE: [PCN] Architecture draft - probing section & general=20 |> |updates. |> | |> | |> |Ruediger, the issue is not addition of one more flow into=20 |> the link that=20 |> |is experiencing (pre-)congestion level for admission but=20 |potentially=20 |> |hundreds of new ingress-egress aggregates that have not been=20 |> |established passing through the link. |> | |> |Regards, Joe |> |email:babiarz@nortel.com |> |Telephone:613-763-6098 |> | |> |-----Original Message----- |> |From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] |> |Sent: October 23, 2007 4:19 AM |> |To: philip.eardley@bt.com |> |Cc: pcn@ietf.org |> |Subject: RE: [PCN] Architecture draft - probing section & general=20 |> |updates. |> | |> |Phil, |> | |> |I appreciate that probing is optional. I understand that to=20 |> mean that=20 |> |standardisation allows to operate PCN within a domain=20 |> without having to=20 |> |support any probing functionality. |> | |> |There may be operational conditions, when probing makes=20 |> sense. This may=20 |> |be the case, if the number of multiplexed flows is at the=20 |> lower bound=20 |> |of the range where statistical multiplexing can be applied=20 |> on any link=20 |> |and the number of possible ingress to egress relations passing this=20 |> |link is big enough to lead to (pre-)congestion by admission=20 |> of a single=20 |> |flow with a reasonable probability. I don't want to stop=20 |people from=20 |> |working on this issue, but I'd favour PCN to finish=20 |standards for an=20 |> |operational environment where the probability of a single=20 |> admitted flow=20 |> |causing congestion on a link is extremly low. |> | |> |Regards, |> | |> |Rudiger |> | |> | |> |_______________________________________________ |> |PCN mailing list |> |PCN@ietf.org |> |https://www1.ietf.org/mailman/listinfo/pcn |> | |>=20 |>=20 |> _______________________________________________ |> PCN mailing list |> PCN@ietf.org |> https://www1.ietf.org/mailman/listinfo/pcn |>=20 | _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Oct 24 11:33:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkiEH-0006Vv-1G; Wed, 24 Oct 2007 11:33:09 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IkiEF-0006VF-KF for pcn-confirm+ok@megatron.ietf.org; Wed, 24 Oct 2007 11:33:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkiEF-0006Uf-A8 for pcn@ietf.org; Wed, 24 Oct 2007 11:33:07 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkiE9-0002Mu-4i for pcn@ietf.org; Wed, 24 Oct 2007 11:33:07 -0400 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l9OFWiT06171; Wed, 24 Oct 2007 15:32:44 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] RSVP and ECMP Date: Wed, 24 Oct 2007 11:32:40 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB646512CCCDAC@zcarhxm1.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] RSVP and ECMP Thread-Index: AcgVndml+QY8RZibTBGng5cn3JfQdAAp7ZnQAAMtV+A= References: <6C20D78B-36AE-4D88-8F7A-20F4D4A512A4@cisco.com> From: "Jozef Babiarz" To: "Anna Charny (acharny)" , "Bruce Davie (bdavie)" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Yes, I think this would be reasonable starting point for PCN. =20 Regards, Joe email:babiarz@nortel.com Telephone:613-763-6098 -----Original Message----- From: Anna Charny (acharny) [mailto:acharny@cisco.com]=20 Sent: October 24, 2007 10:19 AM To: Bruce Davie (bdavie); menth@informatik.uni-wuerzburg.de Cc: pcn@ietf.org Subject: RE: [PCN] RSVP and ECMP Hi all, Bringing this in the context of using RSVP messages for probing. =20 If internal pcn nodes are doing the "standard" load-balancing (i.e. use ip src & dst or the 5-tuple) info from the packet header), then it seems at least two deployment scenarios are "safe" in terms of sending the RSVP messages along the same path as the data: 1) a(per flow) intserv-over-diffserv situation - in this case per-flow rsvp messages will have the appropriate fields used by ecmp the same as the corresponding data packets of this flow 2) an aggregate rsvp reservation coupled with tunnelling. (If tunneling is not used, then if the core does load balancing based on 5-tuple, different flows inside the reservation might be forwarded on different paths) Not so safe cases arise in general when ecmp looks deeper into the packet than the granularity of RSVP message (i.e the "flow" granularity as seen by RSVP is different than the "flow" granularity as seem by ecmp; e.g. when RSVP is used on an mpls tunnel, but the ecmp looks at the 5-tuple). One way to move forward (if we wanted to use RSVP as probes) is to explicitly restrict the deployment scenarios when this is not an issue and make explicit assumptions on how ecmp algorithms work in those deployment scenarios. =20 On second thought making such assumptions may not be too bad, because when they are violated, it seems that the system will then behave no worse than if probing is not used at all. =20 Thoughts? Anna=20 > -----Original Message----- > From: Bruce Davie (bdavie)=20 > Sent: Tuesday, October 23, 2007 1:51 PM > To: menth@informatik.uni-wuerzburg.de > Cc: pcn@ietf.org > Subject: Re: [PCN] RSVP and ECMP >=20 > Michael, > RSVP tries to forward the Path exactly the same way that it=20 > would forward the data. Since Path messages are processed=20 > outside of the fast path, it is possible for the router to=20 > look at anything that is in the path message, including=20 > source addr, dest addr, and port numbers, and figure out=20 > where a data packet that had those values in its IP header=20 > would get forwarded. It sends the Path message out that=20 > interface. In practice, this takes care of the vast majority=20 > of ECMP algorithms. This approach is implemented today. >=20 > If ECMP was using something from the IP or higher layer=20 > header that was not in the Path message, then a problem would arise. >=20 > So, practically speaking, if the probe messages have the=20 > same addresses and ports as the data, they should get correct=20 > ECMP treatment. Or at least, fare no worse than RSVP. >=20 > Bruce >=20 > On Oct 23, 2007, at 12:07 PM, Michael Menth wrote: >=20 > > Hi, > > > > I've got a question regarding RSVP. PATH messages need to=20 > be carried=20 > > over the same path as subsequent data packets. How is this=20 > achieved in=20 > > the presence of ECMP routing? In theory, PATH messages can take a=20 > > different route than data packets if the load balancer=20 > takes arbitrary=20 > > parts of the header(s) to calculate a suitable hash value, which=20 > > decides which route the packet will take. > > > > This issue seems to be related to the problem of how to=20 > make sure that=20 > > PCN probe messages take the same path as subsequent PCN=20 > data packets,=20 > > provided that they have the same source and destination ports and=20 > > addresses. > > > > I am interested in how this problem is solved in practice=20 > or whether=20 > > it is intentionally avoided. > > > > Regards, > > > > Michael > > > > -- > > Dr. Michael Menth, Assistant Professor University of Wuerzburg,=20 > > Institute of Computer Science Am Hubland, D-97074=20 > Wuerzburg, Germany,=20 > > room B206 > > phone: (+49)-931/888-6644, fax: (+49)-931/888-6632=20 > > 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 >=20 >=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn >=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 Wed Oct 24 11:39:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkiKE-0005wa-OJ; Wed, 24 Oct 2007 11:39:18 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IkiKD-0005vP-NI for pcn-confirm+ok@megatron.ietf.org; Wed, 24 Oct 2007 11:39:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkiKD-0005vH-Dd for pcn@ietf.org; Wed, 24 Oct 2007 11:39:17 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkiK7-0002ZY-6R for pcn@ietf.org; Wed, 24 Oct 2007 11:39:17 -0400 X-IronPort-AV: E=Sophos;i="4.21,325,1188792000"; d="scan'208";a="135578088" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 24 Oct 2007 11:38:58 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9OFd0NL017341; Wed, 24 Oct 2007 11:39:00 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l9OFcBkT001676; Wed, 24 Oct 2007 15:39:00 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Oct 2007 11:38:58 -0400 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] Architecture draft - probing section & general updates. Date: Wed, 24 Oct 2007 11:38:57 -0400 Message-ID: In-Reply-To: <1B6169C658325341A3B8066E23919E1C0DE927@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Architecture draft - probing section & general updates. Thread-Index: AcgQFh3bpdXKC6/iTqGKgTMqojS39gFKBadgABQhwRAAHsa+UAAOGxPAAAGwngAAAoF7QA== From: "Anna Charny (acharny)" To: "Geib, Ruediger" X-OriginalArrivalTime: 24 Oct 2007 15:38:58.0690 (UTC) FILETIME=[FE6FDE20:01C81653] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15502.002 X-TM-AS-Result: No--19.822700-8.000000-2 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7352; t=1193240340; x=1194104340; 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]=20Architecture=20draft=20-=20probing=20section= 20&=20general=20updates. |Sender:=20 |To:=20=22Geib,=20Ruediger=22=20; bh=cL9kDOjW1xuIGw0VjtNv9tczKkHqKTK9Ukt79bHSYqg=; b=ip7Z5cNnVmwlV9Mn+MhLIdxwXouurnas63dzHSNrNI969DuAZUxPZIyH/bCa9lCosrD3VHdB 1nWanidl+cz7SbuEZfpQzq+fnugyUZS8w+p3mIWYbj8mfmAmA0ZU61nC; Authentication-Results: rtp-dkim-1; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Ruediger, Thank you - that is very important information. But may I ask why, under these circumstances, one would want to use PCN at all? PCN seems to have the benefit of working in cases when the network is NOT well provisioned for any reason (e.g. under the set of failures that are not provisioned, or when traffic martix differs from the one "predicted" for dimentioning? So what is the motivation to go beyond the current (PCN-free) environment, if we define away those "not-so-well-dimentioned" circumstances as being of no interest? Thank you, Anna=20 > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]=20 > Sent: Wednesday, October 24, 2007 10:41 AM > To: Anna Charny (acharny) > Cc: pcn@ietf.org > Subject: RE: [PCN] Architecture draft - probing section &=20 > general updates. >=20 > Hi Anna, >=20 > one more remark on your question 4) would be, that Deutsche Telekom > - to the extent I'm aware of it - does not plan her network=20 > to provide QoS also during massive failures or flash crowds.=20 > To the best of my knowledge, also consumer organisations rank=20 > our IP network as the best or at least one of the best in Germany.=20 > It is dimensioned to cope with probable failures and=20 > forseeable traffic developments. I doubt that any carrier=20 > acting in a highly competitive market, possibly regulated in=20 > some parts, intends to invest heavily into his network to=20 > provide QoS also under very exceptional operational=20 > conditions. Especially, if a solution working under normal=20 > operational conditions was significantly cheaper or faster=20 > and easier to deploy. >=20 > Regards, >=20 > Rudiger >=20 > |-----Original Message----- > |From: Anna Charny (acharny) [mailto:acharny@cisco.com] > |Sent: Wednesday, October 24, 2007 3:54 PM > |To: Geib, Rudiger; babiarz@nortel.com > |Cc: pcn@ietf.org > |Subject: RE: [PCN] Architecture draft - probing section & general=20 > |updates. > | > | > |Hi all, > | > |I think it boils down to a set of questions below. If=20 > anyone has any=20 > |direct data regarding real-time traffic from today's=20 > Diffserv networks=20 > |(or any futuire projections) that can help answer those=20 > questions, itr=20 > |would help resolve the probing discussion. > | > |1) is it a common occurrence in todays Diffserv networks=20 > (say using EF=20 > |to support real-time traffic) that a large number of=20 > ingress-egress EF=20 > |aggregates have just 1-2 flows? [I do not have direct data but from=20 > |many incidental pieces of information I think the answer may be yes] > | > |2) Is it reasonable to assume that when video becomes=20 > widespread, many=20 > |ingress-egress aggregates might have just 1 video flow? [I=20 > do not see=20 > |why this cannot be the case] > | > |3) Even if many ingress-egress aggregates are small, is it a common=20 > |occurrence that on a bottleneck link inside the network a=20 > large portion=20 > |of the bottleneck bandwidth is taken by those small ingress-egress=20 > |aggregates? > |[It seems a more expected case is when the bottleneck is shared by=20 > |large and small aggregates, and the large aggregates take a=20 > fair amount=20 > |of bandwidth. It this case, under "normal circumstances" when the=20 > |demand on the bottleneck does not drastically exceed the configured=20 > |admission rate, admission control will likely resolve the=20 > |pre-congestion at the expence of the large aggregates.] > | > |4) Are there realistic circumstances (flash crowds or=20 > massive failures=20 > |lasting for some time?) when the load on the bottleneck of small=20 > |aggregates alone might cause substantial overload? (and if=20 > so, should=20 > |we attempt to address these cases for admission or just rely on=20 > |termination? > | > |Anna > | > |=20 > | > |> -----Original Message----- > |> From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > |> Sent: Wednesday, October 24, 2007 3:04 AM > |> To: babiarz@nortel.com > |> Cc: pcn@ietf.org > |> Subject: RE: [PCN] Architecture draft - probing section & general=20 > |> updates. > |>=20 > |> Joe, > |>=20 > |> my perception is, that probing may be useful, once there is=20 > |> pre-congestion. In a situation without a single admitted=20 > flow between=20 > |> an ingress and an egress, if neither ingress node nor egress node=20 > |> have any indication of pre-congestion on any of the links=20 > crossed by=20 > |> the PCN flows passing through them, there's with high=20 > probability no=20 > |> need to probe, I'd assume. I don't do simulations and=20 > would like to=20 > |> invite those simulating to come up with cases where this=20 > assumption=20 > |> is wrong. > |>=20 > |> I'd further propose to collect information from providers on the=20 > |> probability of the event you describe. > |>=20 > |> Regards, > |>=20 > |> Rudiger > |>=20 > |> |-----Original Message----- > |> |From: Jozef Babiarz [mailto:babiarz@nortel.com] > |> |Sent: Tuesday, October 23, 2007 6:22 PM > |> |To: Geib, Rudiger; philip.eardley@bt.com > |> |Cc: pcn@ietf.org > |> |Subject: RE: [PCN] Architecture draft - probing section & general=20 > |> |updates. > |> | > |> | > |> |Ruediger, the issue is not addition of one more flow into > |> the link that > |> |is experiencing (pre-)congestion level for admission but > |potentially > |> |hundreds of new ingress-egress aggregates that have not been=20 > |> |established passing through the link. > |> | > |> |Regards, Joe > |> |email:babiarz@nortel.com > |> |Telephone:613-763-6098 > |> | > |> |-----Original Message----- > |> |From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > |> |Sent: October 23, 2007 4:19 AM > |> |To: philip.eardley@bt.com > |> |Cc: pcn@ietf.org > |> |Subject: RE: [PCN] Architecture draft - probing section & general=20 > |> |updates. > |> | > |> |Phil, > |> | > |> |I appreciate that probing is optional. I understand that to > |> mean that > |> |standardisation allows to operate PCN within a domain > |> without having to > |> |support any probing functionality. > |> | > |> |There may be operational conditions, when probing makes > |> sense. This may > |> |be the case, if the number of multiplexed flows is at the > |> lower bound > |> |of the range where statistical multiplexing can be applied > |> on any link > |> |and the number of possible ingress to egress relations=20 > passing this=20 > |> |link is big enough to lead to (pre-)congestion by admission > |> of a single > |> |flow with a reasonable probability. I don't want to stop > |people from > |> |working on this issue, but I'd favour PCN to finish > |standards for an > |> |operational environment where the probability of a single > |> admitted flow > |> |causing congestion on a link is extremly low. > |> | > |> |Regards, > |> | > |> |Rudiger > |> | > |> | > |> |_______________________________________________ > |> |PCN mailing list > |> |PCN@ietf.org > |> |https://www1.ietf.org/mailman/listinfo/pcn > |> | > |>=20 > |>=20 > |> _______________________________________________ > |> PCN mailing list > |> PCN@ietf.org > |> https://www1.ietf.org/mailman/listinfo/pcn > |>=20 > | >=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Oct 24 12:16:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikisi-0004Un-Fm; Wed, 24 Oct 2007 12:14:56 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Ikish-0004UA-2F for pcn-confirm+ok@megatron.ietf.org; Wed, 24 Oct 2007 12:14:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikisg-0004Nx-OG for pcn@ietf.org; Wed, 24 Oct 2007 12:14:54 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkisY-00048R-Jc for pcn@ietf.org; Wed, 24 Oct 2007 12:14:52 -0400 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l9OGESA02479; Wed, 24 Oct 2007 16:14:28 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Architecture draft - probing section & general updates. Date: Wed, 24 Oct 2007 12:14:21 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB646512CCCEE0@zcarhxm1.corp.nortel.com> In-Reply-To: <1B6169C658325341A3B8066E23919E1C0DE91D@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Architecture draft - probing section & general updates. Thread-Index: AcgQFh3bpdXKC6/iTqGKgTMqojS39gFKBadgABQhwRAAHsa+UAASrNzA References: <9671A92C3C8B5744BC97F855F7CB646512C6F7D0@zcarhxm1.corp.nortel.com> <1B6169C658325341A3B8066E23919E1C0DE91D@S4DE8PSAANK.mitte.t-com.de> From: "Jozef Babiarz" To: "Geib, Ruediger" X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Ruediger,=20 I'm thinking of a scenario that many enterprises face today. Large multi location enterprises use multiple WAN links or VPS to interconnect their locations. PCN is run inside the enterprise network including WAN links which maybe tunneled across the carrier network. Network Access Control with PCN admission control is done at the enterprise access edge nodes. New flows can be routed to any egress access edge node and some flows will (between different locations) be routed over one of the WAN links which are normally bandwidth constrained. There is a high probability that many access nodes will only have one flow between each other as there are a large number of them. Regards, Joe email:babiarz@nortel.com Telephone:613-763-6098 -----Original Message----- From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]=20 Sent: October 24, 2007 3:04 AM To: Babiarz, Jozef (CAR:0S03) Cc: pcn@ietf.org Subject: RE: [PCN] Architecture draft - probing section & general updates. Joe, my perception is, that probing may be useful, once there is=20 pre-congestion. In a situation without a single admitted=20 flow between an ingress and an egress, if neither ingress=20 node nor egress node have any indication of pre-congestion=20 on any of the links crossed by the PCN flows passing through=20 them, there's with high probability no need to probe,=20 I'd assume. I don't do simulations and would like to invite those simulating to come up with cases where this assumption=20 is wrong. I'd further propose to collect information from providers=20 on the probability of the event you describe.=20 Regards,=20 Rudiger |-----Original Message----- |From: Jozef Babiarz [mailto:babiarz@nortel.com] |Sent: Tuesday, October 23, 2007 6:22 PM |To: Geib, Rudiger; philip.eardley@bt.com |Cc: pcn@ietf.org |Subject: RE: [PCN] Architecture draft - probing section & general |updates. | | |Ruediger, the issue is not addition of one more flow into the link that |is experiencing (pre-)congestion level for admission but potentially |hundreds of new ingress-egress aggregates that have not been=20 |established |passing through the link.=20 | |Regards, Joe |email:babiarz@nortel.com |Telephone:613-763-6098 | |-----Original Message----- |From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]=20 |Sent: October 23, 2007 4:19 AM |To: philip.eardley@bt.com |Cc: pcn@ietf.org |Subject: RE: [PCN] Architecture draft - probing section & general |updates. | |Phil, | |I appreciate that probing is optional. I understand that to mean that |standardisation allows to operate PCN within a domain without having to |support any probing functionality. | |There may be operational conditions, when probing makes sense. This may |be the case, if the number of multiplexed flows is at the=20 |lower bound of |the range where statistical multiplexing can be applied on any link and |the number of possible ingress to egress relations passing this link is |big enough to lead to (pre-)congestion by admission of a single flow |with a reasonable probability. I don't want to stop people from working |on this issue, but I'd favour PCN to finish standards for an=20 |operational |environment where the probability of a single admitted flow causing |congestion on a link is extremly low.=20 | |Regards, | |Rudiger | | |_______________________________________________ |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 Oct 24 13:21:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkjvT-0002f8-GY; Wed, 24 Oct 2007 13:21:51 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IkjvR-0002bb-Mm for pcn-confirm+ok@megatron.ietf.org; Wed, 24 Oct 2007 13:21:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkjvR-0002Zn-5w for pcn@ietf.org; Wed, 24 Oct 2007 13:21:49 -0400 Received: from wrzx28.rz.uni-wuerzburg.de ([132.187.3.28] helo=mailrelay.rz.uni-wuerzburg.de) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkjvQ-0003AM-LI for pcn@ietf.org; Wed, 24 Oct 2007 13:21:49 -0400 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id CDD73AD8C for ; Wed, 24 Oct 2007 19:21:47 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id C0AB5B3BB for ; Wed, 24 Oct 2007 19:21:47 +0200 (CEST) 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 ADB92AE7B for ; Wed, 24 Oct 2007 19:21:47 +0200 (CEST) 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 l9OHLlh13316 for ; Wed, 24 Oct 2007 19:21:47 +0200 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id DD8E36F591 for ; Wed, 24 Oct 2007 19:14:30 +0200 (CEST) Message-ID: <471F7D66.1030104@informatik.uni-wuerzburg.de> Date: Wed, 24 Oct 2007 19:14:14 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) 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: 97adf591118a232206bdb5a27b217034 Subject: [PCN] How to determine the ingress and egress node of a packet? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi, PCN edge nodes require the following functions: 1) Upon an admission request, the ingress node needs to figure out to which egress node packets of a flow will be sent to. This information is required to determine the ingress-egress-aggregate associated with the new flow which is necessary for the admission decision. When probing is used for all requests, this function is not required as the probe packets are carried to the corresponding egress node according to the current routing in the network. 2) At each packet arrival, the egress node needs to associate the packet with its corresponding ingress-egress aggregate. This information is required to update the correct packet statistics for the CLE with the marking information of the packet. Both problems seem similar to me. What's a viable solution of these problems such that it is feasible in practice? Ok, MPLS makes the mapping easy, but I guess we want to come up with a PCN solution that doesn't require MPLS? 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 Oct 24 15:06:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IklYH-0001Az-VH; Wed, 24 Oct 2007 15:06:01 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IklYG-0001As-C4 for pcn-confirm+ok@megatron.ietf.org; Wed, 24 Oct 2007 15:06:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IklYF-00014L-Kz for pcn@ietf.org; Wed, 24 Oct 2007 15:05:59 -0400 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IklY8-0006kp-Pp for pcn@ietf.org; Wed, 24 Oct 2007 15:05:53 -0400 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.63]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Oct 2007 20:05:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PCN] PCN & tunnelling Date: Wed, 24 Oct 2007 20:05:51 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC5F7@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN & tunnelling Thread-Index: AcgWJ+54M2I8eYc4QJu/kWUfuySz/QAGbMXgAAt1T+A= From: To: , X-OriginalArrivalTime: 24 Oct 2007 19:05:51.0618 (UTC) FILETIME=[E51E5E20:01C81670] X-Spam-Score: 0.0 (/) X-Scan-Signature: dadeebe491e67c033a493fd3c7d6792b Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1336389931==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1336389931== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C81670.E4E34CA2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C81670.E4E34CA2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Anna, =20 I don't know. =20 For inspiration, I looked at rfc2983, diffserv & tunnels. S3.2 of this talks about partially capable DS configs - only tunnel ingress is DS-capable but not the egress. It says that=20 If tunnel decapsulation processing discards the outer header's DSCP value without changing the inner header's DSCP value, the DS-capable tunnel ingress node is obligated to set the inner header's DSCP to a value compatible with the network at the tunnel egress. The value 0 [is a good suggestion] =20 this approach is along the same lines to the one in the original email below. Unfortunately 2983 doesn't say how the tunnel ingress node knows about the characteristics of the network at the tunnel egress. Did the DS people have anything in mind that might apply in the PCN case? =20 phil =20 -----Original Message----- From: Anna Charny (acharny) [mailto:acharny@cisco.com]=20 Sent: 24 October 2007 14:30 To: Eardley,PL,Philip,CXR9 R; pcn@ietf.org Subject: RE: [PCN] PCN & tunnelling =20 Hi Phil, =20 Question: what would be the mechanism for knowing whether the egress of the tunnel is in the PCN domain or not? Are we assuming that a node somehow advertises its PCN capability? I do not think we ever explicitly assumed that? =20 Anna=20 =20 =09 ________________________________ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: Wednesday, October 24, 2007 6:24 AM To: pcn@ietf.org Subject: [PCN] PCN & tunnelling Hi, =20 I was chatting with Bob about section 5.8 tunnelling. We've realised there's the following nasty case which we hadn't thought about. The scenario is when a tunnel starts inside a PCN-domain and finishes outside it.=20 =20 First we follow what happens when the current text is followed. Imagine that the pkt is PCN-marked by some PCN-node before the tunnel start node. On encapsulation the PCN-mark is copied onto the outer header. Hence the PCN-egress-node 'sees' the PCN-mark as normal - this is ok. The PCN-egress-node clears the marking in the (outer) header and forwards the pkt into the next domain. The pkt is decapsulated at the tunnel end point. But the decapsulated pkt is already PCN-marked. Potential problems: [1] if it's decapsulated in a non-PCN-domain, then the pkt may confuse nodes in this domain [depending on what encoding is used for a PCN-mark] ; [2] if it's decapsulated in a PCN-domain, then the pkt is PCN-marked [which might lead this PCN-domain to terminate or block a flow unnecessarily]. =20 The problem arises because the PCN-egress-node clears PCN-marking on the outer header but not on the inner header. (This is a new problem compared with ECN & tunnelling.)=20 =20 Possible solution: if the pkt is PCN-marked, then the tunnel start node checks whether the tunnel egress is inside or outside the PCN-domain - if it's outside, then it clears the PCN-marking on the inner header (effectively it does this on behalf of the PCN-egress-node). (Also, the PCN-mark is copied onto the outer header, as the current text says.) =20 Thoughts? =20 Thanks, Phil/ =20 ------_=_NextPart_001_01C81670.E4E34CA2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Anna,

 

I don’t = know.

 

For inspiration, I looked at = rfc2983, diffserv & tunnels. S3.2 of this talks about partially capable DS = configs – only tunnel ingress is DS-capable but not the egress. It says that = 

If tunnel decapsulation processing =
discards
   the outer header's DSCP value =
without changing the inner header's
   DSCP value, the DS-capable =
tunnel ingress node is obligated to set
   the inner header's DSCP to a =
value compatible with the network at the
   tunnel egress.  The value 0 =
[is a good suggestion]

 

this approach is along the same = lines to the one in the original email below. Unfortunately 2983 doesn’t = say how the tunnel ingress node knows about the characteristics of the network at = the tunnel egress. Did the DS people have anything in mind that might apply = in the PCN case?

 

phil

 

-----Original Message-----
From: Anna Charny = (acharny) [mailto:acharny@cisco.com]
Sent: 24 October 2007 = 14:30
To: = Eardley,PL,Philip,CXR9 R; pcn@ietf.org
Subject: RE: [PCN] PCN = & tunnelling

 

Hi Phil,

 

Question: what would be the = mechanism for knowing whether the egress of the tunnel is in the PCN domain or = not?  Are we assuming that a node somehow advertises its PCN capability?  I = do not think we ever explicitly assumed that?

 

Anna

 

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: Wednesday, October = 24, 2007 6:24 AM
To: pcn@ietf.org
Subject: [PCN] PCN & tunnelling

Hi,

 

I was chatting with Bob about section 5.8 tunnelling. = We’ve realised there’s the following nasty case which we hadn’t = thought about. The scenario is when a tunnel starts inside a PCN-domain and = finishes outside it.

 

First we follow what happens when the current text is followed. = Imagine that the pkt is PCN-marked by some PCN-node before the tunnel start = node. On encapsulation the PCN-mark is copied onto the outer header. Hence the PCN-egress-node ‘sees’ the PCN-mark as normal – this = is ok. The PCN-egress-node clears the marking in the (outer) header and = forwards the pkt into the next domain. The pkt is decapsulated at the tunnel end = point. But the decapsulated pkt is already PCN-marked. Potential problems: [1] if it’s decapsulated in a non-PCN-domain, then the pkt may confuse = nodes in this domain [depending on what encoding is used for a PCN-mark] ; [2] if it’s decapsulated in a PCN-domain, then the pkt is PCN-marked = [which might lead this PCN-domain to terminate or block a flow = unnecessarily].

 

The problem arises because the PCN-egress-node clears = PCN-marking on the outer header but not on the inner header. (This is a new problem = compared with ECN & tunnelling.)

 

Possible solution: if the pkt is PCN-marked, then the tunnel = start node checks whether the tunnel egress is inside or outside the PCN-domain - = if it’s outside, then it clears the PCN-marking on the inner header (effectively it does this on behalf of the PCN-egress-node). (Also, the PCN-mark is copied onto the outer header, as the current text = says.)

 

Thoughts?

 

Thanks,

Phil/  

=00 ------_=_NextPart_001_01C81670.E4E34CA2-- --===============1336389931== 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 --===============1336389931==-- From pcn-bounces@ietf.org Wed Oct 24 15:06:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IklZ5-0001aK-DT; Wed, 24 Oct 2007 15:06:51 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IklZ4-0001Vt-4i for pcn-confirm+ok@megatron.ietf.org; Wed, 24 Oct 2007 15:06:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IklZ2-0001SJ-S2 for pcn@ietf.org; Wed, 24 Oct 2007 15:06:49 -0400 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IklZ2-0006mE-6k for pcn@ietf.org; Wed, 24 Oct 2007 15:06:48 -0400 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.63]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Oct 2007 20:06:47 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PCN] PCN & tunnelling Date: Wed, 24 Oct 2007 20:06:47 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC5F8@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <1B6169C658325341A3B8066E23919E1C0DE924@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN & tunnelling Thread-Index: AcgWJ+54M2I8eYc4QJu/kWUfuySz/QABQXZQAA2JTqA= From: To: X-OriginalArrivalTime: 24 Oct 2007 19:06:47.0495 (UTC) FILETIME=[066C8570:01C81671] X-Spam-Score: 0.0 (/) X-Scan-Signature: 182294e3fdac3aef093c0503b87ed133 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1516154670==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1516154670== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C81671.064462A2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C81671.064462A2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ruediger, =20 Yes, it is a more general problem. I've been trying to read 2983 [diffserv & tunnels] and 3270 [mpls & diffserv - similar kinds of issues] =20 2983 has 2 conceptual models, Uniform & Pipe: - Uniform: tunnel is an artefact on the e2e path from a traffic conditioning viewpoint; pkt effectively has one DS field that's used for traffic conditioning. Copy DSCP value to the outer header at encaps and copy outer header's dscp value to inner IP header at decaps.=20 - Pipe: IP tunnel hides the nodes so they don't really participate in traffic conditioning. Tunnel egress ignores the outer header's dscp & uses the inner header's DSCP (or rather the traffic conditioning info it conveys - to cover the case where the same meaning is encoded by different values of dscp). Tunnel links DS domains at end points into a diffserv region ('virtually' contiguous).=20 =20 When it comes to PCN & tunnels, something analogous to the Uniform model seems more appropriate to me - ie the pkt effectively has one field for PCN-marking that's used for PCN-based adm ctrl (& termination); the operation is at decaps, if the outer header's PCN-marking is more severe than the inner IP header's, then copy it to the inner IP header.=20 At least I think the Uniform model is best for the normal (?) case where the tunnel is within the PCN-domain - because we want all nodes in the PCN-domain to be able potentially to PCN-mark & hence contribute to the adm ctrl decisions. If the tunnel is partly within a PCN-domain and partly outside I think the uniform model is still the right one (not too sure - there are lots of things complicating it, some of which mentioned in first email below, but I think the conceptual model should still be the same].=20 =20 Ruediger: question about what you call 'downpropagation', I assume this is the copying operation I refer to in the Uniform model. I agree with you for PCN marking [text is already in the archit draft on these lines]. However, you also mention downpropagation of DSCP which I don't think is correct.=20 =20 Ruediger, you mention where the DSCP values have different meanings at the tunnel ingress & egress (tunnel crosses a diffserv domain boundary). Yes, I believe this is a general diffserv issue and is covered by 2475. =20 phil =20 -----Original Message----- From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]=20 Sent: 24 October 2007 12:10 To: Eardley,PL,Philip,CXR9 R Cc: pcn@ietf.org Subject: RE: [PCN] PCN & tunnelling =20 Phil, =20 I guess this is a general DiffServ issue too. In case [2] you assume the same DSCP to be used by the tunnel end point PCN domain as at the tunnel entry. This assumption may not hold, if the set DSCP is used for another service class or unused at the end point.=20 =20 I had a brief glance on RFC2983, "Differentiated Services and Tunnels". Downpropagation of outer IP header DSCP/PCN settings may be a fairly good recommendation. =20 Regards, =20 Rudiger -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: Wednesday, October 24, 2007 12:24 PM To: pcn@ietf.org Subject: [PCN] PCN & tunnelling Hi, =20 I was chatting with Bob about section 5.8 tunnelling. We've realised there's the following nasty case which we hadn't thought about. The scenario is when a tunnel starts inside a PCN-domain and finishes outside it.=20 =20 First we follow what happens when the current text is followed. Imagine that the pkt is PCN-marked by some PCN-node before the tunnel start node. On encapsulation the PCN-mark is copied onto the outer header. Hence the PCN-egress-node 'sees' the PCN-mark as normal - this is ok. The PCN-egress-node clears the marking in the (outer) header and forwards the pkt into the next domain. The pkt is decapsulated at the tunnel end point. But the decapsulated pkt is already PCN-marked. Potential problems: [1] if it's decapsulated in a non-PCN-domain, then the pkt may confuse nodes in this domain [depending on what encoding is used for a PCN-mark] ; [2] if it's decapsulated in a PCN-domain, then the pkt is PCN-marked [which might lead this PCN-domain to terminate or block a flow unnecessarily]. =20 The problem arises because the PCN-egress-node clears PCN-marking on the outer header but not on the inner header. (This is a new problem compared with ECN & tunnelling.)=20 =20 Possible solution: if the pkt is PCN-marked, then the tunnel start node checks whether the tunnel egress is inside or outside the PCN-domain - if it's outside, then it clears the PCN-marking on the inner header (effectively it does this on behalf of the PCN-egress-node). (Also, the PCN-mark is copied onto the outer header, as the current text says.) =20 Thoughts? =20 Thanks, Phil/ =20 ------_=_NextPart_001_01C81671.064462A2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ruediger,

 

Yes, it is a more general problem. = I’ve been trying to read 2983 [diffserv & tunnels] and 3270 [mpls & = diffserv – similar kinds of issues]

 

2983 has 2 conceptual models, = Uniform & Pipe:

- Uniform: tunnel is an artefact on = the e2e path from a traffic conditioning viewpoint; pkt effectively has one = DS field that’s used for traffic conditioning. Copy DSCP value to the = outer header at encaps and copy outer header’s dscp value to inner IP = header at decaps.

- Pipe: IP tunnel hides the nodes = so they don’t really participate in traffic conditioning. Tunnel egress ignores the = outer header’s dscp & uses the inner header’s DSCP (or rather = the traffic conditioning info it conveys – to cover the case where the same = meaning is encoded by different values of dscp). Tunnel links DS domains at end = points into a diffserv region (‘virtually’ contiguous). =

 

When it comes to PCN & tunnels, = something analogous to the Uniform model seems more appropriate to me – ie = the pkt effectively has one field for PCN-marking that’s used for = PCN-based adm ctrl (& termination); the operation is at decaps, if the outer = header’s PCN-marking is more severe than the inner IP header’s, then copy = it to the inner IP header.

At least I think the Uniform model = is best for the normal (?) case where the tunnel is within the PCN-domain = – because we want all nodes in the PCN-domain to be able potentially to = PCN-mark & hence contribute to the adm ctrl decisions. If the tunnel is = partly within a PCN-domain and partly outside I think the uniform model is still the = right one (not too sure – there are lots of things complicating it, some = of which mentioned in first email below, but I think the conceptual model = should still be the same].

 

Ruediger: question about what you = call ‘downpropagation’, I assume this is the copying operation I refer to in the Uniform model. = I agree with you for PCN marking [text is already in the archit draft on these = lines]. However, you also mention downpropagation of DSCP which I don’t think is = correct.

 

Ruediger, you mention where the = DSCP values have different meanings at the tunnel ingress & egress (tunnel = crosses a diffserv domain boundary). Yes, I believe this is a general diffserv issue and is = covered by 2475.

 

phil

 

-----Original Message-----
From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]
Sent: 24 October 2007 12:10
To: = Eardley,PL,Philip,CXR9 R
Cc: pcn@ietf.org
Subject: RE: [PCN] PCN = & tunnelling

 

Phil,

 

I guess this is a general DiffServ = issue too. In case [2] you assume the same DSCP to be used by the tunnel = end point PCN domain as at the tunnel entry. This assumption may not hold, = if the set DSCP is used for another service class or unused at the end = point.

 

I had a brief glance on RFC2983, "Differentiated Services and Tunnels". Downpropagation of = outer IP header DSCP/PCN settings may be a fairly good = recommendation.

 

Regards,

 

Rudiger

-----Original = Message-----
From: = philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: Wednesday, October = 24, 2007 12:24 PM
To: pcn@ietf.org
Subject: [PCN] PCN & tunnelling

Hi,

 

I was chatting with Bob about section 5.8 tunnelling. = We’ve realised there’s the following nasty case which we hadn’t = thought about. The scenario is when a tunnel starts inside a PCN-domain and = finishes outside it.

 

First we follow what happens when the current text is followed. = Imagine that the pkt is PCN-marked by some PCN-node before the tunnel start = node. On encapsulation the PCN-mark is copied onto the outer header. Hence the PCN-egress-node ‘sees’ the PCN-mark as normal – this = is ok. The PCN-egress-node clears the marking in the (outer) header and = forwards the pkt into the next domain. The pkt is decapsulated at the tunnel end = point. But the decapsulated pkt is already PCN-marked. Potential problems: [1] if it’s decapsulated in a non-PCN-domain, then the pkt may confuse = nodes in this domain [depending on what encoding is used for a PCN-mark] ; [2] if = it’s decapsulated in a PCN-domain, then the pkt is PCN-marked [which might = lead this PCN-domain to terminate or block a flow = unnecessarily].

 

The problem arises because the PCN-egress-node clears = PCN-marking on the outer header but not on the inner header. (This is a new problem = compared with ECN & tunnelling.)

 

Possible solution: if the pkt is PCN-marked, then the tunnel = start node checks whether the tunnel egress is inside or outside the PCN-domain - = if it’s outside, then it clears the PCN-marking on the inner header (effectively it does this on behalf of the PCN-egress-node). (Also, the PCN-mark is copied onto the outer header, as the current text = says.)

 

Thoughts?

 

Thanks,

Phil/  

=00 ------_=_NextPart_001_01C81671.064462A2-- --===============1516154670== 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 --===============1516154670==-- From pcn-bounces@ietf.org Thu Oct 25 04:59:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkyXr-0000A8-Eq; Thu, 25 Oct 2007 04:58:27 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IkyXp-00006Y-QO for pcn-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 04:58:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkyXl-0008TN-2c for pcn@ietf.org; Thu, 25 Oct 2007 04:58:21 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkyXa-00046i-Mf for pcn@ietf.org; Thu, 25 Oct 2007 04:58:17 -0400 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Thu, 25 Oct 2007 10:57:35 +0200 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Oct 2007 10:57:35 +0200 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] Architecture draft - probing section & general updates. Date: Thu, 25 Oct 2007 10:57:35 +0200 Message-Id: <1B6169C658325341A3B8066E23919E1C4C1329@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Architecture draft - probing section & general updates. thread-index: AcgQFh3bpdXKC6/iTqGKgTMqojS39gFKBadgABQhwRAAHsa+UAAOGxPAAAGwngAAAoF7QAAj+SHA From: "Geib, Ruediger" To: X-OriginalArrivalTime: 25 Oct 2007 08:57:35.0677 (UTC) FILETIME=[164176D0:01C816E5] X-Spam-Score: -1.0 (-) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Anna, using PCN (hopefully) allows to engineer a network to stay below a=20 certain "PCN flow block ratio" and make sure by stopping=20 admission, that even during times of likely network distortions=20 (like single link/router failures) the QoS of admitted PCN=20 flows remains as guaranteed by an SLA. Briefly, it is trading flow blocking for a better performance=20 of admitted flows under most common operational conditions. Please note that Telekom's backbone network is dimensionsed=20 with redundant capacity. It further fully supports DiffServ. Regards, Rudiger =20 |-----Original Message----- |From: Anna Charny (acharny) [mailto:acharny@cisco.com] |Sent: Wednesday, October 24, 2007 5:39 PM |To: Geib, Rudiger |Cc: pcn@ietf.org |Subject: RE: [PCN] Architecture draft - probing section & general |updates. | | |Hi Ruediger, | |Thank you - that is very important information. But may I ask why, |under these circumstances, one would want to use PCN at all? PCN seems |to have the benefit of working in cases when the network is NOT well |provisioned for any reason (e.g. under the set of failures that are not |provisioned, or when traffic martix differs from the one=20 |"predicted" for |dimentioning? So what is the motivation to go beyond the current |(PCN-free) environment, if we define away those |"not-so-well-dimentioned" circumstances as being of no interest? | |Thank you, |Anna=20 | |> -----Original Message----- |> From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]=20 |> Sent: Wednesday, October 24, 2007 10:41 AM |> To: Anna Charny (acharny) |> Cc: pcn@ietf.org |> Subject: RE: [PCN] Architecture draft - probing section &=20 |> general updates. |>=20 |> Hi Anna, |>=20 |> one more remark on your question 4) would be, that Deutsche Telekom |> - to the extent I'm aware of it - does not plan her network=20 |> to provide QoS also during massive failures or flash crowds.=20 |> To the best of my knowledge, also consumer organisations rank=20 |> our IP network as the best or at least one of the best in Germany.=20 |> It is dimensioned to cope with probable failures and=20 |> forseeable traffic developments. I doubt that any carrier=20 |> acting in a highly competitive market, possibly regulated in=20 |> some parts, intends to invest heavily into his network to=20 |> provide QoS also under very exceptional operational=20 |> conditions. Especially, if a solution working under normal=20 |> operational conditions was significantly cheaper or faster=20 |> and easier to deploy. |>=20 |> Regards, |>=20 |> Rudiger |>=20 |> |-----Original Message----- |> |From: Anna Charny (acharny) [mailto:acharny@cisco.com] |> |Sent: Wednesday, October 24, 2007 3:54 PM |> |To: Geib, Rudiger; babiarz@nortel.com |> |Cc: pcn@ietf.org |> |Subject: RE: [PCN] Architecture draft - probing section & general=20 |> |updates. |> | |> | |> |Hi all, |> | |> |I think it boils down to a set of questions below. If=20 |> anyone has any=20 |> |direct data regarding real-time traffic from today's=20 |> Diffserv networks=20 |> |(or any futuire projections) that can help answer those=20 |> questions, itr=20 |> |would help resolve the probing discussion. |> | |> |1) is it a common occurrence in todays Diffserv networks=20 |> (say using EF=20 |> |to support real-time traffic) that a large number of=20 |> ingress-egress EF=20 |> |aggregates have just 1-2 flows? [I do not have direct data=20 |but from=20 |> |many incidental pieces of information I think the answer may be yes] |> | |> |2) Is it reasonable to assume that when video becomes=20 |> widespread, many=20 |> |ingress-egress aggregates might have just 1 video flow? [I=20 |> do not see=20 |> |why this cannot be the case] |> | |> |3) Even if many ingress-egress aggregates are small, is it a common=20 |> |occurrence that on a bottleneck link inside the network a=20 |> large portion=20 |> |of the bottleneck bandwidth is taken by those small ingress-egress=20 |> |aggregates? |> |[It seems a more expected case is when the bottleneck is shared by=20 |> |large and small aggregates, and the large aggregates take a=20 |> fair amount=20 |> |of bandwidth. It this case, under "normal circumstances" when the=20 |> |demand on the bottleneck does not drastically exceed the configured=20 |> |admission rate, admission control will likely resolve the=20 |> |pre-congestion at the expence of the large aggregates.] |> | |> |4) Are there realistic circumstances (flash crowds or=20 |> massive failures=20 |> |lasting for some time?) when the load on the bottleneck of small=20 |> |aggregates alone might cause substantial overload? (and if=20 |> so, should=20 |> |we attempt to address these cases for admission or just rely on=20 |> |termination? |> | |> |Anna |> | |> |=20 |> | |> |> -----Original Message----- |> |> From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] |> |> Sent: Wednesday, October 24, 2007 3:04 AM |> |> To: babiarz@nortel.com |> |> Cc: pcn@ietf.org |> |> Subject: RE: [PCN] Architecture draft - probing section & general=20 |> |> updates. |> |>=20 |> |> Joe, |> |>=20 |> |> my perception is, that probing may be useful, once there is=20 |> |> pre-congestion. In a situation without a single admitted=20 |> flow between=20 |> |> an ingress and an egress, if neither ingress node nor egress node=20 |> |> have any indication of pre-congestion on any of the links=20 |> crossed by=20 |> |> the PCN flows passing through them, there's with high=20 |> probability no=20 |> |> need to probe, I'd assume. I don't do simulations and=20 |> would like to=20 |> |> invite those simulating to come up with cases where this=20 |> assumption=20 |> |> is wrong. |> |>=20 |> |> I'd further propose to collect information from providers on the=20 |> |> probability of the event you describe. |> |>=20 |> |> Regards, |> |>=20 |> |> Rudiger |> |>=20 |> |> |-----Original Message----- |> |> |From: Jozef Babiarz [mailto:babiarz@nortel.com] |> |> |Sent: Tuesday, October 23, 2007 6:22 PM |> |> |To: Geib, Rudiger; philip.eardley@bt.com |> |> |Cc: pcn@ietf.org |> |> |Subject: RE: [PCN] Architecture draft - probing section=20 |& general=20 |> |> |updates. |> |> | |> |> | |> |> |Ruediger, the issue is not addition of one more flow into |> |> the link that |> |> |is experiencing (pre-)congestion level for admission but |> |potentially |> |> |hundreds of new ingress-egress aggregates that have not been=20 |> |> |established passing through the link. |> |> | |> |> |Regards, Joe |> |> |email:babiarz@nortel.com |> |> |Telephone:613-763-6098 |> |> | |> |> |-----Original Message----- |> |> |From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] |> |> |Sent: October 23, 2007 4:19 AM |> |> |To: philip.eardley@bt.com |> |> |Cc: pcn@ietf.org |> |> |Subject: RE: [PCN] Architecture draft - probing section=20 |& general=20 |> |> |updates. |> |> | |> |> |Phil, |> |> | |> |> |I appreciate that probing is optional. I understand that to |> |> mean that |> |> |standardisation allows to operate PCN within a domain |> |> without having to |> |> |support any probing functionality. |> |> | |> |> |There may be operational conditions, when probing makes |> |> sense. This may |> |> |be the case, if the number of multiplexed flows is at the |> |> lower bound |> |> |of the range where statistical multiplexing can be applied |> |> on any link |> |> |and the number of possible ingress to egress relations=20 |> passing this=20 |> |> |link is big enough to lead to (pre-)congestion by admission |> |> of a single |> |> |flow with a reasonable probability. I don't want to stop |> |people from |> |> |working on this issue, but I'd favour PCN to finish |> |standards for an |> |> |operational environment where the probability of a single |> |> admitted flow |> |> |causing congestion on a link is extremly low. |> |> | |> |> |Regards, |> |> | |> |> |Rudiger |> |> | |> |> | |> |> |_______________________________________________ |> |> |PCN mailing list |> |> |PCN@ietf.org |> |> |https://www1.ietf.org/mailman/listinfo/pcn |> |> | |> |>=20 |> |>=20 |> |> _______________________________________________ |> |> PCN mailing list |> |> PCN@ietf.org |> |> https://www1.ietf.org/mailman/listinfo/pcn |> |>=20 |> | |>=20 | _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Oct 25 05:04:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkydM-0007TI-At; Thu, 25 Oct 2007 05:04:08 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IkydL-0007Sz-4A for pcn-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 05:04:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkydK-0007Sr-Oz for pcn@ietf.org; Thu, 25 Oct 2007 05:04:06 -0400 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkydJ-00009J-PF for pcn@ietf.org; Thu, 25 Oct 2007 05:04:06 -0400 Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id l9P93wZT005651; Thu, 25 Oct 2007 11:04:03 +0200 (MEST) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Thu, 25 Oct 2007 09:03:58 +0000 To: "philip.eardley@bt.com" , "anurag.bhargava@ericsson.com" , "pcn@ietf.org" Subject: RE: [PCN] LC-PCN version 01 uploaded Date: Thu, 25 Oct 2007 09:03:58 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC4E4@E03MVZ1-UKDY.domain1.systemhost.net> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0 () 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]); Thu, 25 Oct 2007 11:04:04 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Phil, Hi all Sorry for the delay! Due to sad family circumstances I could not concentrate on the PCN activities! Thank you very muh for reading and commenting the LC-PCN draft. Below I try to answer the questions associated with the LC-PCN draft. Best regards, Georgios > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: donderdag 13 september 2007 17:27 > To: anurag.bhargava@ericsson.com; pcn@ietf.org > Subject: RE: [PCN] LC-PCN version 01 uploaded > > Anurag > > Thanks for the revised draft, I can understand it much > better. Here are some questions /misunderstandings. > > Let me summarise to make sure I understand it right. > > - two encodings are used. one ('PCN-marking') is used for > both adm ctrl & termination to indicate the excess traffic. > If a PCN-interior-node is PCN-marking some pkts, then it > marks all other pkts with another encoding ('affected marking') Georgios: Yes, you are right. All other packets are marked using the "PCN_Affected_marking" encoding. > > - the 'PCN-marking' algorithm has several regimes: > * when traffic rate is below PCN-lower-rate, no pkts are marked > * as the traffic rate climbs above the PCN-lower-rate, an > increasing number of pkts are marked (marking rate =3D excess > rate divided by N) [adm ctrl state] Georgios: It is more complicated than that! Please check the pseudocode on page 13. The packets are PCN-marking encoded only if the incoming_PCN_marking_rate is smaller or equal to the Admission_offset_rate. Where the incoming_PCN_marking_rate is actualy the rate of incoming packets that are PCN_marked. > * at some rate (PCN-lower-rate + adm-offset-rate), then pkts > are marked at the same rate, even if the traffic rate climbs > higher [adm ctrl state] Georgios: No, if the incoming_PCN_marking_rate is higher than the Admission_offset_rate than no anymore packets are PCN_marked. They are however marked as PCN_Affected_marking! > * when the traffic rate reaches the PCN-upper-rate, > additional pkts are marked (additional marking rate =3D excess > rate above PCN-upper-rate divided by N) [termination ctrl state] Georgios: It is again more complicated than that, please see the pseudocode on Page 20. Similar to the admission control state the rate of packets to be marked also depends on the incoming_PCN_marking_rate. Moreover, if the interior node is in termination ctrl state then the additional marking rate is using the sliding window algorithm to overcome the undershooting issue, see page 19 and page 20. > * if pkts arrive already PCN-marked, then the node measures > the rate of pkts already marked & works out what excess rate > this corresponds to, and only marks additional pkts if its > own excess rate is even higher. Georgios: Well, it is more complicated than that. Please see pseudo code onn page 13 and page 20, the rate of the already PCN_marked packets is denoted in the pseudocode as incoming_PCN_marking_rate. > * the PCN-egress-node measures the rate of PCN-marked pkts > and determines whether the overloaded node is in adm ctrl > state or termination ctrl state Georgios: Yes, but it is more complicated than that please see pseudo code on page 14 and on page 23. > > Questions: > - I don't understand the point of doing PCN-marking in the adm ctrl > state. When it comes to making an adm decision, you send a (single) > probe pkt - if it's PCN-marked or affected-marked then you block the > call. So when a node's in the adm ctrl state, it could just do > affected-marking of all pkts. Wouldn't that work just as well? Georgios: this algorithm can provide admission control even if probing is not used. However, by using probing we ensure that the flow that is requesting access is passing through the interior node that is either in admission control state or flow termination state. > - with you current algo, imagine there are two paths through the nw: > A-B-X-D > A-M-N-X-D > If B & N are both in adm ctrl state then they both will do > PCN-marking. > At the PCN-egress-node the PCN-marking rate may be high enough that it > believes termination is needed. Are there topologies/scenarios where > this could happen? I think your multicongestion_error > parameter in S3.4 > is connected to this problem; I didn't find your discussion about it > convincing Georgios: You are right, the multicongestion_error parameter in S3.4 is used to emphasize the multicongestion error bounds in this calculation. Note that the calculation of this error bound can only be estimated by off line tests in a predefined network scenario. Note that by using the dependency of the incoming_PCN_marking_rate the multicongestion error bound can be decreased. > - the 'affected marking' is claimed to solve ECMP issues. However, the > same affected marking is used in both adm ctrl state & > termination ctrl > state - I don't think this works. Imagine that a node [node-1] on one > path is in adm ctrl state & a node [node-2] on another path is in > termination ctrl state. Therefore flows are terminated, and only flows > that are being PCN-marked or affected-marked are terminated. However > this could lead to flows being terminated that go through > node-1; node-2 > will still be just as badly overloaded. Georgios: In admission control state, probing is used to ensure that the packets associated to a requesting flow are passing through the congested PCN_interior node. ECMP is one of the issues that are associated with the fact that packets of a flow can follow a different path than the path followed by an aggregate of flows (starting from the same ingress and ending at the same egress). In order to accomplish this the probe packets should be marked using either PCN_marking encoding or the PCN_Affected_marking encoding. In flow termination state, both the PCN_marking and PCN_Affected_marking encoded packets are used to ensure that the flows that are selected for termination are indeed passing through a severely congested node. Note that the issue that you described above is associated to the multicongestion-error bounds. Therefore, this multicongestion-error bound should be estimated as much as accurate as possible. > - in the termination algorithm, S4.2.2, the "termination_offset_rate" > factor makes no sense to me Georgios: Why not? > - the parameters PCN_lower_rate_egress & PCN_upper_rate_egress are > expressed in the wrong units (you have conditions like > signalled_overload_rate > PCN_lower_rate_egress; the former is a rate, > the latter a % so some tweaking is needed to convert the latter into a > rate) Georgios: You are right, a conversion is needed to convert the latter into a rate. > > best wishes > > phil/ > > > -----Original Message----- > > From: Anurag Bhargava (RL/TNT) [mailto:anurag.bhargava@ericsson.com] > > Sent: 11 September 2007 12:36 > > To: pcn > > Subject: [PCN] LC-PCN version 01 uploaded > > > > Hello, > > FYI - We have uploaded a new version of the PCN draft. The major > > changes are some clarification and adopting to the > Architecture draft > > terminology. > > > > "LC-PCN: The Load Control PCN Solution", Lars Westberg, 5-Sep-07, > > > > > > Please let me know if you have any questions. > > > > Thanks, > > -Anurag Bhargava, Ph.D. > > > > > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www1.ietf.org/mailman/listinfo/pcn > > > _______________________________________________ > 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 Oct 25 05:10:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkyjC-0001A6-RS; Thu, 25 Oct 2007 05:10:10 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IkyjB-00019f-9o for pcn-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 05:10:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkyjA-00017n-2j for pcn@ietf.org; Thu, 25 Oct 2007 05:10:08 -0400 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ikyj9-0000Kg-7m for pcn@ietf.org; Thu, 25 Oct 2007 05:10:07 -0400 Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id l9P99x0O006100; Thu, 25 Oct 2007 11:10:03 +0200 (MEST) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Thu, 25 Oct 2007 09:09:59 +0000 To: "Jozef Babiarz" , "Anna Charny (acharny)" , "Lars Eggert" Subject: RE: Correction: RE: [PCN] Architecture draft - probing section & general updates. Date: Thu, 25 Oct 2007 09:09:58 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <9671A92C3C8B5744BC97F855F7CB646512B4E7B4@zcarhxm1.corp.nortel.com> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0 () 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]); Thu, 25 Oct 2007 11:10:05 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: "pcn@ietf.org" X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi all I agree with Joe that the architecture and the selection of PCN marking approach needs to take into consideration that probing may be part of some solutions/deployments and that details will be defined at some future time. Best regards, Georgios On 10/19/2007, "Jozef Babiarz" wrote: >I agree with Anna, and would like to add that the marking mechanism in >core network needs to work equally well when ingress-egress aggregates >passing through bottleneck router have small or large number of flows. >Choosing marking approach that only works for one case is not that >useful, at lest to me and my customers that are interested in PCN. > >On the probing issue, there are many (two+) methods currently defined >and some already used in IP networks as well new methods that could be >defined for possible use with PCN for admission control. I'm OK with >deferring the selection of already defined protocol(s) or definition of >new probing protocol until later date. However, I believe strongly that >the architecture and the selection of PCN marking approach needs to take >into consideration that probing may be part of some >solutions/deployments and that details will be defined at some future >time.=20 > >Regards, Joe >email:babiarz@nortel.com >Telephone:613-763-6098 >-----Original Message----- >From: Anna Charny (acharny) [mailto:acharny@cisco.com]=20 >Sent: October 19, 2007 9:25 AM >To: Anna Charny (acharny); Lars Eggert >Cc: pcn@ietf.org >Subject: Correction: RE: [PCN] Architecture draft - probing section & >general updates. > >A typo in my previous message: I meant to say the charter does NOT >restrict the low ingress-egress aggregation. Edited the appropriate >sentense below... > >Anna > >> -----Original Message----- >> From: Anna Charny (acharny)=20 >> Sent: Friday, October 19, 2007 9:23 AM >> To: 'Lars Eggert' >> Cc: Hancock, Robert; philip.eardley@bt.com; pcn@ietf.org >> Subject: RE: [PCN] Architecture draft - probing section &=20 >> general updates. >>=20 >> Hi Lars, >>=20 >> On the low agfgregation point, please see below:=20 >>=20 >> > -----Original Message----- >> > From: Lars Eggert [mailto:lars.eggert@nokia.com] >> > Sent: Friday, October 19, 2007 8:58 AM >> > To: Anna Charny (acharny) >> > Cc: Hancock, Robert; philip.eardley@bt.com; pcn@ietf.org >> > Subject: Re: [PCN] Architecture draft - probing section & general=20 >> > updates. >> >=20 >> > On 2007-10-16, at 21:55, ext Anna Charny (acharny) wrote: >> > > Yes, Robert's is a fair concern to which no obvious=20 >> solution is in=20 >> > > sight. Different equipment might use different algorithms=20 >> and might=20 >> > > use different fields for ECMP load-balancing under different=20 >> > > circumstances. >> > > IMHO this is a killer argument of why the use of probing for=20 >> > > discovering the state of ECMP paths should not be=20 >> considered within=20 >> > > the scope of PCN WG. >> >=20 >> > Agreed. >> >=20 >> > > There remains a question of whether probing can/should be >> > considerd to >> > > probe the path regardless of the ECMP issue. I see most of >> > its value >> > > in flash crowd situations in combination with low ingress-egress=20 >> > > agregation. >> >=20 >> > I note that scenarios with low aggregation aren't in scope of the >> > charter: >> >=20 >> > The initial scope of the PCN WG is restricted by the following >> > assumptions: >> > ... >> > (C) the number of flows across any potential aggregation=20 >> bottleneck >> > is sufficiently large for stateless, statistical mechanisms >> > to be effective >>=20 >> Actually, I did not mean low aggregation *at the=20 >> bottleneck*, which is what the charter seems to restrict. =20 >> Rather I meant the case when the bottleneck has high=20 >> aggregation, but traffic on that bottleneck comes from a=20 >> large number of ingress-egress pairs, each having very low=20 >> aggregation levels. I believe technically the charter does NOT=20 >> put any explicit restrictions on the scope for ingress-egress=20 >> aggregation.=20 >>=20 >> Perhaps the WG should consider whether it is reasonable to=20 >> impose restrictions on the *ingress-egress* aggregation=20 >> levels as well. An argument can be made that in practice a=20 >> large number of ingress-egress pairs may only have a few=20 >> flows, even when the bottleneck aggregations are large.=20 >>=20 >> The decision on whether low ingress-egress aggregation level=20 >> is in scope seems to be important for choosing among the=20 >> various approaches proposed to the WG, as some of them are=20 >> substantially more sensitive to the low ingress-egress=20 >> aggregations than others (e.g. single marking does not=20 >> perform well at very low levels of aggregation, as we showed=20 >> at the last meeting). =20 >>=20 >> Perhaps an explicit discussion on the assumptions regarding=20 >> the expected levels of ingress-egress aggregations is needed=20 >> on the list?=20 >>=20 >> Towards that discussion, my personal view is that in the long=20 >> range ignoring low levels of ingress-egress aggregation=20 >> levels will severely limit the viability/usefulness of the=20 >> technology. However, perhaps as an initial step it would be=20 >> OK to assume moderate to high aggregation levels, as long as=20 >> a clear path is visible on how to address low aggregations in=20 >> the future within the scope of defined behaviors. But I=20 >> think it is important to have a clear consensus on this point.=20 >>=20 >> Anna=20 >>=20 >> >=20 >> > Lars >> >=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 Thu Oct 25 05:20:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikysz-00071W-La; Thu, 25 Oct 2007 05:20:17 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Ikysy-00071N-8Q for pcn-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 05:20:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikysx-00071A-Rl for pcn@ietf.org; Thu, 25 Oct 2007 05:20:15 -0400 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ikysx-0000bL-88 for pcn@ietf.org; Thu, 25 Oct 2007 05:20:15 -0400 Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id l9P9KCuN006991; Thu, 25 Oct 2007 11:20:12 +0200 (MEST) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Thu, 25 Oct 2007 09:20:12 +0000 To: "Bruce Davie" , "menth@informatik.uni-wuerzburg.de" Subject: Re: [PCN] RSVP and ECMP Date: Thu, 25 Oct 2007 09:20:12 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: <7i9binUY.1193304012.0627110.karagian@ewi.utwente.nl> In-Reply-To: <6C20D78B-36AE-4D88-8F7A-20F4D4A512A4@cisco.com> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0 () 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]); Thu, 25 Oct 2007 11:20:13 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: "pcn@ietf.org" X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Bruce, Hi all I agree with Bruce! If it is to use probing, then we have to ensure that the probes should get the similar correct ECMP treatment as the correct ECMP treatment achieved by RSVP. This means that the probe messages have to have the same addresses and ports as the data. I think tat this is not difficult and not complex to be achieved. Best regards, Georgios On 10/23/2007, "Bruce Davie" wrote: >Michael, > RSVP tries to forward the Path exactly the same way that it would >forward the data. Since Path messages are processed outside of the >fast path, it is possible for the router to look at anything that is >in the path message, including source addr, dest addr, and port >numbers, and figure out where a data packet that had those values in >its IP header would get forwarded. It sends the Path message out that >interface. In practice, this takes care of the vast majority of ECMP >algorithms. This approach is implemented today. > > If ECMP was using something from the IP or higher layer header that >was not in the Path message, then a problem would arise. > > So, practically speaking, if the probe messages have the same >addresses and ports as the data, they should get correct ECMP >treatment. Or at least, fare no worse than RSVP. > >Bruce > >On Oct 23, 2007, at 12:07 PM, Michael Menth wrote: > >> Hi, >> >> I've got a question regarding RSVP. PATH messages need to be >> carried over the same path as subsequent data packets. How is this >> achieved in the presence of ECMP routing? In theory, PATH messages >> can take a different route than data packets if the load balancer >> takes arbitrary parts of the header(s) to calculate a suitable hash >> value, which decides which route the packet will take. >> >> This issue seems to be related to the problem of how to make sure >> that PCN probe messages take the same path as subsequent PCN data >> packets, provided that they have the same source and destination >> ports and addresses. >> >> I am interested in how this problem is solved in practice or >> whether it is intentionally avoided. >> >> 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 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Oct 25 05:31:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikz3A-0003x9-M3; Thu, 25 Oct 2007 05:30:48 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Ikz39-0003us-Jp for pcn-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 05:30:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikz38-0003uj-Q1 for pcn@ietf.org; Thu, 25 Oct 2007 05:30:46 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ikz38-0000sX-0R for pcn@ietf.org; Thu, 25 Oct 2007 05:30:46 -0400 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Thu, 25 Oct 2007 11:30:36 +0200 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Oct 2007 11:30:06 +0200 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] Architecture draft - probing section & general updates. Date: Thu, 25 Oct 2007 11:30:05 +0200 Message-Id: <1B6169C658325341A3B8066E23919E1C4C132A@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <9671A92C3C8B5744BC97F855F7CB646512CCCEE0@zcarhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Architecture draft - probing section & general updates. thread-index: AcgQFh3bpdXKC6/iTqGKgTMqojS39gFKBadgABQhwRAAHsa+UAASrNzAACRENBA= From: "Geib, Ruediger" To: X-OriginalArrivalTime: 25 Oct 2007 09:30:06.0146 (UTC) FILETIME=[A0D36A20:01C816E9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Joe, if I understand you right, the PCN ingress/egress nodes are CPEs=20 (or the like) connected to a single carriers network and this=20 carrier supports PCN. Is that correct? While there are many different accesses and a high number=20 access to access communications, each single access carries=20 aggregated traffic from some origins only (but not from all). The accesses probably capture congestion information from WAN=20 links close to them - the number of those usually is=20 restricted and some of the already admitted flows pass them. Without any congestion feedback/indication on ingress or egress - admit the next flow. Otherwise, probing may be useful. My own perception of PCN would be more carrier centric, assuming=20 the PCN edge nodes to be part of the carrier network and not=20 of the customers. But this doesn't necessary invalidate your=20 example. Regards, Rudiger |-----Original Message----- |From: Jozef Babiarz [mailto:babiarz@nortel.com] |Sent: Wednesday, October 24, 2007 6:14 PM |To: Geib, Rudiger |Cc: pcn@ietf.org |Subject: RE: [PCN] Architecture draft - probing section & general |updates. | | |Ruediger,=20 |I'm thinking of a scenario that many enterprises face today.=20 |Large multi |location enterprises use multiple WAN links or VPS to=20 |interconnect their |locations. PCN is run inside the enterprise network including WAN links |which maybe tunneled across the carrier network. Network Access Control |with PCN admission control is done at the enterprise access edge nodes. |New flows can be routed to any egress access edge node and some flows |will (between different locations) be routed over one of the WAN links |which are normally bandwidth constrained. There is a high probability |that many access nodes will only have one flow between each other as |there are a large number of them. | |Regards, Joe |email:babiarz@nortel.com |Telephone:613-763-6098 | |-----Original Message----- |From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]=20 |Sent: October 24, 2007 3:04 AM |To: Babiarz, Jozef (CAR:0S03) |Cc: pcn@ietf.org |Subject: RE: [PCN] Architecture draft - probing section & general |updates. | |Joe, | |my perception is, that probing may be useful, once there is=20 |pre-congestion. In a situation without a single admitted=20 |flow between an ingress and an egress, if neither ingress=20 |node nor egress node have any indication of pre-congestion=20 |on any of the links crossed by the PCN flows passing through=20 |them, there's with high probability no need to probe,=20 |I'd assume. I don't do simulations and would like to invite |those simulating to come up with cases where this assumption=20 |is wrong. | |I'd further propose to collect information from providers=20 |on the probability of the event you describe.=20 | |Regards,=20 | |Rudiger | ||-----Original Message----- ||From: Jozef Babiarz [mailto:babiarz@nortel.com] ||Sent: Tuesday, October 23, 2007 6:22 PM ||To: Geib, Rudiger; philip.eardley@bt.com ||Cc: pcn@ietf.org ||Subject: RE: [PCN] Architecture draft - probing section & general ||updates. || || ||Ruediger, the issue is not addition of one more flow into the=20 |link that ||is experiencing (pre-)congestion level for admission but potentially ||hundreds of new ingress-egress aggregates that have not been=20 ||established ||passing through the link.=20 || ||Regards, Joe ||email:babiarz@nortel.com ||Telephone:613-763-6098 || ||-----Original Message----- ||From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]=20 ||Sent: October 23, 2007 4:19 AM ||To: philip.eardley@bt.com ||Cc: pcn@ietf.org ||Subject: RE: [PCN] Architecture draft - probing section & general ||updates. || ||Phil, || ||I appreciate that probing is optional. I understand that to mean that ||standardisation allows to operate PCN within a domain without=20 |having to ||support any probing functionality. || ||There may be operational conditions, when probing makes=20 |sense. This may ||be the case, if the number of multiplexed flows is at the=20 ||lower bound of ||the range where statistical multiplexing can be applied on=20 |any link and ||the number of possible ingress to egress relations passing=20 |this link is ||big enough to lead to (pre-)congestion by admission of a single flow ||with a reasonable probability. I don't want to stop people=20 |from working ||on this issue, but I'd favour PCN to finish standards for an=20 ||operational ||environment where the probability of a single admitted flow causing ||congestion on a link is extremly low.=20 || ||Regards, || ||Rudiger || || ||_______________________________________________ ||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 Oct 25 05:36:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikz8t-00017N-1F; Thu, 25 Oct 2007 05:36:43 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Ikz8s-000153-AR for pcn-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 05:36:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikz8r-000137-Vv for pcn@ietf.org; Thu, 25 Oct 2007 05:36:41 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ikz8l-0005fR-L1 for pcn@ietf.org; Thu, 25 Oct 2007 05:36:41 -0400 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Thu, 25 Oct 2007 11:36:28 +0200 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Oct 2007 11:36:28 +0200 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] Architecture draft - probing section & general updates. Date: Thu, 25 Oct 2007 11:36:28 +0200 Message-Id: <1B6169C658325341A3B8066E23919E1C4C132B@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <9671A92C3C8B5744BC97F855F7CB646512CCCEE0@zcarhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Architecture draft - probing section & general updates. thread-index: AcgQFh3bpdXKC6/iTqGKgTMqojS39gFKBadgABQhwRAAHsa+UAASrNzAACVCMmA= From: "Geib, Ruediger" To: X-OriginalArrivalTime: 25 Oct 2007 09:36:28.0646 (UTC) FILETIME=[84D04860:01C816EA] X-Spam-Score: -1.0 (-) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Joe, as an add on: if these are all CPEs and probing is=20 restricted to CPEs, it doesn't matter much to me.=20 I'm having more of a problem, if a backbone edge=20 router or any other backbone edge system=20 (like carrier VoIP gateways) are expected to probe. If it is the CPE which is probing, this traffic is=20 standard PCN traffic to the carrier. It is forwarded=20 and accounted like standard PCN traffic by the carrier. Regards, Rudiger |-----Original Message----- |From: Jozef Babiarz [mailto:babiarz@nortel.com] |Sent: Wednesday, October 24, 2007 6:14 PM |To: Geib, Rudiger |Cc: pcn@ietf.org |Subject: RE: [PCN] Architecture draft - probing section & general |updates. | | |Ruediger,=20 |I'm thinking of a scenario that many enterprises face today.=20 |Large multi |location enterprises use multiple WAN links or VPS to=20 |interconnect their |locations. PCN is run inside the enterprise network including WAN links |which maybe tunneled across the carrier network. Network Access Control |with PCN admission control is done at the enterprise access edge nodes. |New flows can be routed to any egress access edge node and some flows |will (between different locations) be routed over one of the WAN links |which are normally bandwidth constrained. There is a high probability |that many access nodes will only have one flow between each other as |there are a large number of them. | |Regards, Joe |email:babiarz@nortel.com |Telephone:613-763-6098 | |-----Original Message----- |From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]=20 |Sent: October 24, 2007 3:04 AM |To: Babiarz, Jozef (CAR:0S03) |Cc: pcn@ietf.org |Subject: RE: [PCN] Architecture draft - probing section & general |updates. | |Joe, | |my perception is, that probing may be useful, once there is=20 |pre-congestion. In a situation without a single admitted=20 |flow between an ingress and an egress, if neither ingress=20 |node nor egress node have any indication of pre-congestion=20 |on any of the links crossed by the PCN flows passing through=20 |them, there's with high probability no need to probe,=20 |I'd assume. I don't do simulations and would like to invite |those simulating to come up with cases where this assumption=20 |is wrong. | |I'd further propose to collect information from providers=20 |on the probability of the event you describe.=20 | |Regards,=20 | |Rudiger | ||-----Original Message----- ||From: Jozef Babiarz [mailto:babiarz@nortel.com] ||Sent: Tuesday, October 23, 2007 6:22 PM ||To: Geib, Rudiger; philip.eardley@bt.com ||Cc: pcn@ietf.org ||Subject: RE: [PCN] Architecture draft - probing section & general ||updates. || || ||Ruediger, the issue is not addition of one more flow into the=20 |link that ||is experiencing (pre-)congestion level for admission but potentially ||hundreds of new ingress-egress aggregates that have not been=20 ||established ||passing through the link.=20 || ||Regards, Joe ||email:babiarz@nortel.com ||Telephone:613-763-6098 || ||-----Original Message----- ||From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]=20 ||Sent: October 23, 2007 4:19 AM ||To: philip.eardley@bt.com ||Cc: pcn@ietf.org ||Subject: RE: [PCN] Architecture draft - probing section & general ||updates. || ||Phil, || ||I appreciate that probing is optional. I understand that to mean that ||standardisation allows to operate PCN within a domain without=20 |having to ||support any probing functionality. || ||There may be operational conditions, when probing makes=20 |sense. This may ||be the case, if the number of multiplexed flows is at the=20 ||lower bound of ||the range where statistical multiplexing can be applied on=20 |any link and ||the number of possible ingress to egress relations passing=20 |this link is ||big enough to lead to (pre-)congestion by admission of a single flow ||with a reasonable probability. I don't want to stop people=20 |from working ||on this issue, but I'd favour PCN to finish standards for an=20 ||operational ||environment where the probability of a single admitted flow causing ||congestion on a link is extremly low.=20 || ||Regards, || ||Rudiger || || ||_______________________________________________ ||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 Oct 25 05:48:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkzK8-00077o-Dj; Thu, 25 Oct 2007 05:48:20 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IkzK6-00075Z-Lx for pcn-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 05:48:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkzK6-00075R-7Y for pcn@ietf.org; Thu, 25 Oct 2007 05:48:18 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkzK5-0001KG-DG for pcn@ietf.org; Thu, 25 Oct 2007 05:48:18 -0400 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Thu, 25 Oct 2007 11:48:09 +0200 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Oct 2007 11:48:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PCN] PCN & tunnelling Date: Thu, 25 Oct 2007 11:48:08 +0200 Message-Id: <1B6169C658325341A3B8066E23919E1C4C132C@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC5F8@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN & tunnelling thread-index: AcgWJ+54M2I8eYc4QJu/kWUfuySz/QABQXZQAA2JTqAAIfRrQA== From: "Geib, Ruediger" To: X-OriginalArrivalTime: 25 Oct 2007 09:48:09.0411 (UTC) FILETIME=[26808930:01C816EC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9d7e8d783239e9f0c425c823a9c950ff Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0597437933==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0597437933== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C816EC.26181EBF" This is a multi-part message in MIME format. ------_=_NextPart_001_01C816EC.26181EBF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Phil, =20 by propagating down DSCP and PCN settings at a tunnel end, a router can make sure that the next hop is able to correctly interpret these values - if this next hop is within its own domain. If the tunnel end is an edge router and the next hop is part of a different domain, then the edge router should neither change the inner header DSCP nor the PCN codepoints. Is that what you think of? =20 Regards, =20 Rudiger -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: Wednesday, October 24, 2007 9:07 PM To: Geib, Rudiger Cc: pcn@ietf.org Subject: RE: [PCN] PCN & tunnelling Ruediger, =20 Yes, it is a more general problem. I've been trying to read 2983 [diffserv & tunnels] and 3270 [mpls & diffserv - similar kinds of issues] =20 2983 has 2 conceptual models, Uniform & Pipe: - Uniform: tunnel is an artefact on the e2e path from a traffic conditioning viewpoint; pkt effectively has one DS field that's used for traffic conditioning. Copy DSCP value to the outer header at encaps and copy outer header's dscp value to inner IP header at decaps.=20 - Pipe: IP tunnel hides the nodes so they don't really participate in traffic conditioning. Tunnel egress ignores the outer header's dscp & uses the inner header's DSCP (or rather the traffic conditioning info it conveys - to cover the case where the same meaning is encoded by different values of dscp). Tunnel links DS domains at end points into a diffserv region ('virtually' contiguous).=20 =20 When it comes to PCN & tunnels, something analogous to the Uniform model seems more appropriate to me - ie the pkt effectively has one field for PCN-marking that's used for PCN-based adm ctrl (& termination); the operation is at decaps, if the outer header's PCN-marking is more severe than the inner IP header's, then copy it to the inner IP header.=20 At least I think the Uniform model is best for the normal (?) case where the tunnel is within the PCN-domain - because we want all nodes in the PCN-domain to be able potentially to PCN-mark & hence contribute to the adm ctrl decisions. If the tunnel is partly within a PCN-domain and partly outside I think the uniform model is still the right one (not too sure - there are lots of things complicating it, some of which mentioned in first email below, but I think the conceptual model should still be the same].=20 =20 Ruediger: question about what you call 'downpropagation', I assume this is the copying operation I refer to in the Uniform model. I agree with you for PCN marking [text is already in the archit draft on these lines]. However, you also mention downpropagation of DSCP which I don't think is correct.=20 =20 Ruediger, you mention where the DSCP values have different meanings at the tunnel ingress & egress (tunnel crosses a diffserv domain boundary). Yes, I believe this is a general diffserv issue and is covered by 2475. =20 phil =20 -----Original Message----- From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]=20 Sent: 24 October 2007 12:10 To: Eardley,PL,Philip,CXR9 R Cc: pcn@ietf.org Subject: RE: [PCN] PCN & tunnelling =20 Phil, =20 I guess this is a general DiffServ issue too. In case [2] you assume the same DSCP to be used by the tunnel end point PCN domain as at the tunnel entry. This assumption may not hold, if the set DSCP is used for another service class or unused at the end point.=20 =20 I had a brief glance on RFC2983, "Differentiated Services and Tunnels". Downpropagation of outer IP header DSCP/PCN settings may be a fairly good recommendation. =20 Regards, =20 Rudiger -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: Wednesday, October 24, 2007 12:24 PM To: pcn@ietf.org Subject: [PCN] PCN & tunnelling Hi, =20 I was chatting with Bob about section 5.8 tunnelling. We've realised there's the following nasty case which we hadn't thought about. The scenario is when a tunnel starts inside a PCN-domain and finishes outside it.=20 =20 First we follow what happens when the current text is followed. Imagine that the pkt is PCN-marked by some PCN-node before the tunnel start node. On encapsulation the PCN-mark is copied onto the outer header. Hence the PCN-egress-node 'sees' the PCN-mark as normal - this is ok. The PCN-egress-node clears the marking in the (outer) header and forwards the pkt into the next domain. The pkt is decapsulated at the tunnel end point. But the decapsulated pkt is already PCN-marked. Potential problems: [1] if it's decapsulated in a non-PCN-domain, then the pkt may confuse nodes in this domain [depending on what encoding is used for a PCN-mark] ; [2] if it's decapsulated in a PCN-domain, then the pkt is PCN-marked [which might lead this PCN-domain to terminate or block a flow unnecessarily]. =20 The problem arises because the PCN-egress-node clears PCN-marking on the outer header but not on the inner header. (This is a new problem compared with ECN & tunnelling.)=20 =20 Possible solution: if the pkt is PCN-marked, then the tunnel start node checks whether the tunnel egress is inside or outside the PCN-domain - if it's outside, then it clears the PCN-marking on the inner header (effectively it does this on behalf of the PCN-egress-node). (Also, the PCN-mark is copied onto the outer header, as the current text says.) =20 Thoughts? =20 Thanks, Phil/ =20 ------_=_NextPart_001_01C816EC.26181EBF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Phil,
 
by=20 propagating down DSCP and PCN settings at a tunnel end, a router = can make=20 sure that the next hop is able to correctly interpret these values - if = this=20 next hop is within its own domain. If the tunnel end is an edge router = and the=20 next hop is part of a different domain, then the edge router should = neither=20 change the inner header DSCP nor the PCN codepoints. Is that what you = think=20 of?
 
Regards,
 
Rudiger
 ------_=_NextPart_001_01C816EC.26181EBF-- --===============0597437933== 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 --===============0597437933==-- From pcn-bounces@ietf.org Thu Oct 25 05:51:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkzNK-000475-NR; Thu, 25 Oct 2007 05:51:38 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IkzNI-00044S-Rp for pcn-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 05:51:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkzNI-00044J-H2 for pcn@ietf.org; Thu, 25 Oct 2007 05:51:36 -0400 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkzNI-0001OB-6q for pcn@ietf.org; Thu, 25 Oct 2007 05:51:36 -0400 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.63]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Oct 2007 10:51:35 +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 & tunnelling Date: Thu, 25 Oct 2007 10:51:34 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC5F9@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <471F233A.4060203@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN & tunnelling Thread-Index: AcgWLKPQAvL8yLicT4+hfWPx9AJY+wAvWGNg From: To: X-OriginalArrivalTime: 25 Oct 2007 09:51:35.0513 (UTC) FILETIME=[A1593490:01C816EC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Michael Am re-writing tunnelling section and wanted to come back to an issue you raise in http://www1.ietf.org/mail-archive/web/pcn/current/msg00687.html.=20 " 1st problem: how do we find the ingress node X of the packet at its PCN egress Y?" I don't see why tunnelling makes this harder, assuming that the signalling msg (or whatever is setting up the PCN-flow) follows the same path as the data will.=20 Thanks phil _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Oct 25 05:55:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkzQh-00080e-2w; Thu, 25 Oct 2007 05:55:07 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IkzQf-00080X-Pt for pcn-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 05:55:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkzQf-0007zi-Dk for pcn@ietf.org; Thu, 25 Oct 2007 05:55:05 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkzQe-0001ZA-SH for pcn@ietf.org; Thu, 25 Oct 2007 05:55:05 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9P9si8g005257; Thu, 25 Oct 2007 12:55:02 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Oct 2007 12:54:37 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Oct 2007 12:54:36 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Oct 2007 12:54:36 +0300 Received: from [172.21.35.48] (esdhcp03548.research.nokia.com [172.21.35.48]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9P9sZYp027042; Thu, 25 Oct 2007 12:54:35 +0300 In-Reply-To: <9671A92C3C8B5744BC97F855F7CB646512CCCEE0@zcarhxm1.corp.nortel.com> References: <9671A92C3C8B5744BC97F855F7CB646512C6F7D0@zcarhxm1.corp.nortel.com> <1B6169C658325341A3B8066E23919E1C0DE91D@S4DE8PSAANK.mitte.t-com.de> <9671A92C3C8B5744BC97F855F7CB646512CCCEE0@zcarhxm1.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <9EE2BE22-5E19-4625-B368-3A603728ED52@nokia.com> From: Lars Eggert Subject: Re: [PCN] Architecture draft - probing section & general updates. Date: Thu, 25 Oct 2007 12:54:29 +0300 To: ext Jozef Babiarz X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 25 Oct 2007 09:54:37.0046 (UTC) FILETIME=[0D8CF160:01C816ED] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: pcn@ietf.org, "Geib, Ruediger" X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1884103659==" Errors-To: pcn-bounces@ietf.org --===============1884103659== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-67-250505094; protocol="application/pkcs7-signature" --Apple-Mail-67-250505094 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-10-24, at 19:14, ext Jozef Babiarz wrote: > I'm thinking of a scenario that many enterprises face today. Large > multi > location enterprises use multiple WAN links or VPS to interconnect > their > locations. PCN is run inside the enterprise network including WAN > links > which maybe tunneled across the carrier network. Network Access > Control > with PCN admission control is done at the enterprise access edge > nodes. > New flows can be routed to any egress access edge node and some flows > will (between different locations) be routed over one of the WAN links > which are normally bandwidth constrained. I understand your scenario so far. > There is a high probability > that many access nodes will only have one flow between each other as > there are a large number of them. I don't see how this follows, however. It seems that if the sites that are being interconnected aren't tiny, there should very likely be multiple flows per ingress/egress pair, no? Lars --Apple-Mail-67-250505094 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzEwMjUwOTU0MzBaMCMGCSqGSIb3DQEJBDEWBBR6jkXGz02Xtadi e5zxXbhNcXE88zCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEADuyfB+qPueZDikaO7+XtsiIEutDKUNf9RoFqbzHlaWtAyccO0KS5 3ZXn+y3kWG35cNoDYdl9RieKzl+oVwjh+z1vATstPrZam5vFz9MT55jHh13ON1qZuSN1XwOlxsGo pQZ+isP0wc8onWFUoJvcvbEM3Tf7YQr0PW2ZMTDINl8OuaH6q/TC1uFTPnXYV1PmsxSRwnz4assT Fm7+Isu3Az+ca9GEQ/pOB8YFEHtfUIhj1a1NUXsfh2G9rvuYSSVp9YRVBjoVmrvXY4pzSa0X1fzh w/t0L26kYKRC5/XH4G6KWqj+HaIKT8dcQTdqYPqnrXpSNMQ4r8PCroEgRnhTcgAAAAAAAA== --Apple-Mail-67-250505094-- --===============1884103659== 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 --===============1884103659==-- From pcn-bounces@ietf.org Thu Oct 25 06:13:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikzil-00077n-Gu; Thu, 25 Oct 2007 06:13:47 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Ikzij-00077J-HP for pcn-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 06:13:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikzij-00077B-1y for pcn@ietf.org; Thu, 25 Oct 2007 06:13:45 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ikzii-00020J-BO for pcn@ietf.org; Thu, 25 Oct 2007 06:13:44 -0400 Received: (qmail invoked by alias); 25 Oct 2007 10:13:43 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp004) with SMTP; 25 Oct 2007 12:13:43 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/7iqlBYqX7Jv8gRoguPSqqLyWIB8WqNZ3jZ4pbuw hKFpLCEzfJdtLQ Message-ID: <47206C56.80809@gmx.net> Date: Thu, 25 Oct 2007 12:13:42 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Georgios Karagiannis Subject: Re: [PCN] RSVP and ECMP References: <7i9binUY.1193304012.0627110.karagian@ewi.utwente.nl> In-Reply-To: <7i9binUY.1193304012.0627110.karagian@ewi.utwente.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: "pcn@ietf.org" X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org The problems obviously show up if the load balancing device does not inspect the RSVP traffic. Then, you cannot ensure that the signaling traffic follows the data traffic anymore. Also with tunnels you need to ensure that at least one of the tunnel endpoints is aware of the signaling protocol. This might seem to be a simple requirement but I assume in reality it is not that easy. This is the area where complexity says HELLO to path-coupled signaling. Ciao Hannes PS: When you still think that it is totally trivial then you might want to look at the many tunneling schemes folks use or want to use. Georgios Karagiannis wrote: > Hi Bruce, Hi all > > I agree with Bruce! If it is to use probing, then we have to ensure > that the probes should get the similar correct ECMP treatment as the > correct ECMP treatment achieved by RSVP. > > This means that the probe messages have to have the same addresses and > ports as the data. > I think tat this is not difficult and not complex to be achieved. > > Best regards, > Georgios > > > > On 10/23/2007, "Bruce Davie" wrote: > > >> Michael, >> RSVP tries to forward the Path exactly the same way that it would >> forward the data. Since Path messages are processed outside of the >> fast path, it is possible for the router to look at anything that is >> in the path message, including source addr, dest addr, and port >> numbers, and figure out where a data packet that had those values in >> its IP header would get forwarded. It sends the Path message out that >> interface. In practice, this takes care of the vast majority of ECMP >> algorithms. This approach is implemented today. >> >> If ECMP was using something from the IP or higher layer header that >> was not in the Path message, then a problem would arise. >> >> So, practically speaking, if the probe messages have the same >> addresses and ports as the data, they should get correct ECMP >> treatment. Or at least, fare no worse than RSVP. >> >> Bruce >> >> On Oct 23, 2007, at 12:07 PM, Michael Menth wrote: >> >> >>> Hi, >>> >>> I've got a question regarding RSVP. PATH messages need to be >>> carried over the same path as subsequent data packets. How is this >>> achieved in the presence of ECMP routing? In theory, PATH messages >>> can take a different route than data packets if the load balancer >>> takes arbitrary parts of the header(s) to calculate a suitable hash >>> value, which decides which route the packet will take. >>> >>> This issue seems to be related to the problem of how to make sure >>> that PCN probe messages take the same path as subsequent PCN data >>> packets, provided that they have the same source and destination >>> ports and addresses. >>> >>> I am interested in how this problem is solved in practice or >>> whether it is intentionally avoided. >>> >>> 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 >> > > > _______________________________________________ > 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 Oct 25 06:41:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il09S-00087Y-Qe; Thu, 25 Oct 2007 06:41:22 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Il09R-00081x-HD for pcn-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 06:41:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il09Q-0007wA-OX for pcn@ietf.org; Thu, 25 Oct 2007 06:41:20 -0400 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Il09G-0007Xg-NS for pcn@ietf.org; Thu, 25 Oct 2007 06:41:16 -0400 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.63]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Oct 2007 11:40:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PCN] PCN & tunnelling Date: Thu, 25 Oct 2007 11:40:54 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC5FA@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <1B6169C658325341A3B8066E23919E1C4C132C@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN & tunnelling Thread-Index: AcgWJ+54M2I8eYc4QJu/kWUfuySz/QABQXZQAA2JTqAAIfRrQAAApIIg From: To: X-OriginalArrivalTime: 25 Oct 2007 10:40:55.0486 (UTC) FILETIME=[85A13DE0:01C816F3] X-Spam-Score: -1.0 (-) X-Scan-Signature: 9ef34681c09171229a7cb90dad7dd8e0 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1364694787==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1364694787== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C816F3.85468EBF" This is a multi-part message in MIME format. ------_=_NextPart_001_01C816F3.85468EBF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm going to leave commenting on the DSCP stuff to diffserv experts. = Anyway, I assume the answer is "whatever happens in a diffserv network" = - I don't see why the existence of PCN would make any odds. =20 Your other point is about what happens if the tunnel egress is at the = PCN-egress-node. I agree with the basic point I think you're making, = that there's no need for the copying operations when the tunnel egress = is at the PCN-egress-node - or indeed when the tunnel ingress is at the = PCN-ingress-node. Ie the values specific to the pcn-domain shouldn't be = used outside. However I don't think your method necessarily works - for = instance if the tunnel starts inside the PCN-domain - the = PCN-egress-node still needs to do PCN-colouring ie sets the dscp & ecn = fields to the values appropriate for use in the next domain =20 =20 Another way of looking at this (I think) is that tunnel ingress = functions are done before PCN-ingress-node functions, and tunnel egress = functions are done after PCN-egress functions does its PCN-metering = function but before its PCN-colouring function.=20 =20 Phil/=20 =20 =20 -----Original Message----- From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]=20 Sent: 25 October 2007 10:48 To: Eardley,PL,Philip,CXR9 R Cc: pcn@ietf.org Subject: RE: [PCN] PCN & tunnelling =20 Phil, =20 by propagating down DSCP and PCN settings at a tunnel end, a router can = make sure that the next hop is able to correctly interpret these values = - if this next hop is within its own domain. If the tunnel end is an = edge router and the next hop is part of a different domain, then the = edge router should neither change the inner header DSCP nor the PCN = codepoints. Is that what you think of? =20 Regards, =20 Rudiger -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: Wednesday, October 24, 2007 9:07 PM To: Geib, R=FCdiger Cc: pcn@ietf.org Subject: RE: [PCN] PCN & tunnelling Ruediger, =20 Yes, it is a more general problem. I've been trying to read 2983 = [diffserv & tunnels] and 3270 [mpls & diffserv - similar kinds of = issues] =20 2983 has 2 conceptual models, Uniform & Pipe: - Uniform: tunnel is an artefact on the e2e path from a traffic = conditioning viewpoint; pkt effectively has one DS field that's used for = traffic conditioning. Copy DSCP value to the outer header at encaps and = copy outer header's dscp value to inner IP header at decaps.=20 - Pipe: IP tunnel hides the nodes so they don't really participate in = traffic conditioning. Tunnel egress ignores the outer header's dscp & = uses the inner header's DSCP (or rather the traffic conditioning info it = conveys - to cover the case where the same meaning is encoded by = different values of dscp). Tunnel links DS domains at end points into a = diffserv region ('virtually' contiguous).=20 =20 When it comes to PCN & tunnels, something analogous to the Uniform = model seems more appropriate to me - ie the pkt effectively has one = field for PCN-marking that's used for PCN-based adm ctrl (& = termination); the operation is at decaps, if the outer header's = PCN-marking is more severe than the inner IP header's, then copy it to = the inner IP header.=20 At least I think the Uniform model is best for the normal (?) case = where the tunnel is within the PCN-domain - because we want all nodes in = the PCN-domain to be able potentially to PCN-mark & hence contribute to = the adm ctrl decisions. If the tunnel is partly within a PCN-domain and = partly outside I think the uniform model is still the right one (not too = sure - there are lots of things complicating it, some of which mentioned = in first email below, but I think the conceptual model should still be = the same].=20 =20 Ruediger: question about what you call 'downpropagation', I assume this = is the copying operation I refer to in the Uniform model. I agree with = you for PCN marking [text is already in the archit draft on these = lines]. However, you also mention downpropagation of DSCP which I don't = think is correct.=20 =20 Ruediger, you mention where the DSCP values have different meanings at = the tunnel ingress & egress (tunnel crosses a diffserv domain boundary). = Yes, I believe this is a general diffserv issue and is covered by 2475. =20 phil =20 -----Original Message----- From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]=20 Sent: 24 October 2007 12:10 To: Eardley,PL,Philip,CXR9 R Cc: pcn@ietf.org Subject: RE: [PCN] PCN & tunnelling =20 Phil, =20 I guess this is a general DiffServ issue too. In case [2] you assume = the same DSCP to be used by the tunnel end point PCN domain as at the = tunnel entry. This assumption may not hold, if the set DSCP is used for = another service class or unused at the end point.=20 =20 I had a brief glance on RFC2983, "Differentiated Services and Tunnels". = Downpropagation of outer IP header DSCP/PCN settings may be a fairly = good recommendation. =20 Regards, =20 Rudiger -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: Wednesday, October 24, 2007 12:24 PM To: pcn@ietf.org Subject: [PCN] PCN & tunnelling Hi, =20 I was chatting with Bob about section 5.8 tunnelling. We've realised = there's the following nasty case which we hadn't thought about. The = scenario is when a tunnel starts inside a PCN-domain and finishes = outside it.=20 =20 First we follow what happens when the current text is followed. = Imagine that the pkt is PCN-marked by some PCN-node before the tunnel = start node. On encapsulation the PCN-mark is copied onto the outer = header. Hence the PCN-egress-node 'sees' the PCN-mark as normal - this = is ok. The PCN-egress-node clears the marking in the (outer) header and = forwards the pkt into the next domain. The pkt is decapsulated at the = tunnel end point. But the decapsulated pkt is already PCN-marked. = Potential problems: [1] if it's decapsulated in a non-PCN-domain, then = the pkt may confuse nodes in this domain [depending on what encoding is = used for a PCN-mark] ; [2] if it's decapsulated in a PCN-domain, then = the pkt is PCN-marked [which might lead this PCN-domain to terminate or = block a flow unnecessarily]. =20 The problem arises because the PCN-egress-node clears PCN-marking on = the outer header but not on the inner header. (This is a new problem = compared with ECN & tunnelling.)=20 =20 Possible solution: if the pkt is PCN-marked, then the tunnel start = node checks whether the tunnel egress is inside or outside the = PCN-domain - if it's outside, then it clears the PCN-marking on the = inner header (effectively it does this on behalf of the = PCN-egress-node). (Also, the PCN-mark is copied onto the outer header, = as the current text says.) =20 Thoughts? =20 Thanks, Phil/ =20 ------_=_NextPart_001_01C816F3.85468EBF Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I’m going to leave commenting = on the DSCP stuff to diffserv experts. Anyway, I assume the answer is = “whatever happens in a diffserv network” – I don’t see why the = existence of PCN would make any odds.

 

Your other point is about what = happens if the tunnel egress is at the PCN-egress-node. I agree with the basic = point I think you’re making, that there’s no need for the copying = operations when the tunnel egress is at the PCN-egress-node – or indeed when the = tunnel ingress is at the PCN-ingress-node. Ie the values specific to the = pcn-domain = shouldn’t be used outside. However I don’t think your method necessarily works = - for instance if the tunnel starts inside the PCN-domain – the = PCN-egress-node still needs to do PCN-colouring ie sets the dscp & ecn fields to the = values appropriate for use in the next domain =A0

 

Another way of looking at this (I = think) is that tunnel ingress functions are done before PCN-ingress-node = functions, and tunnel egress functions are done after PCN-egress functions does its PCN-metering function but before its PCN-colouring function. =

 

Phil/

 

 

-----Original Message-----
From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]
Sent: 25 October 2007 10:48
To: = Eardley,PL,Philip,CXR9 R
Cc: pcn@ietf.org
Subject: RE: [PCN] PCN = & tunnelling

 

Phil,

 

by propagating down DSCP and PCN = settings at a tunnel end, a router can make sure that the next hop is able = to correctly interpret these values - if this next hop is within its own = domain. If the tunnel end is an edge router and the next hop is part of a = different domain, then the edge router should neither change the inner header DSCP = nor the PCN codepoints. Is that what you think of?

 

Regards,

 

Rudiger

-----Original = Message-----
From: = philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: Wednesday, October = 24, 2007 9:07 PM
To: Geib, R=FCdiger
Cc: pcn@ietf.org
Subject: RE: [PCN] PCN = & tunnelling

Ruediger,

 

Yes, it is a more general problem. I’ve been trying to read 2983 [diffserv & tunnels] and 3270 = [mpls & diffserv – similar kinds of issues]

 

2983 has 2 conceptual models, = Uniform & Pipe:

- Uniform: tunnel is an artefact on = the e2e path from a traffic conditioning viewpoint; pkt effectively has one = DS field that’s used for traffic conditioning. Copy DSCP value to the = outer header at encaps and copy outer header’s dscp value to inner IP = header at decaps.

- Pipe: IP tunnel hides the nodes = so they don’t really participate in traffic conditioning. Tunnel egress = ignores the outer header’s dscp & uses the inner header’s DSCP = (or rather the traffic conditioning info it conveys – to cover the = case where the same meaning is encoded by different values of dscp). Tunnel links = DS domains at end points into a diffserv region (‘virtually’ contiguous).

 

When it comes to PCN & tunnels, something analogous to the Uniform model seems more appropriate to me = – ie the pkt effectively has one field for PCN-marking that’s used = for PCN-based adm ctrl (& termination); the operation is at decaps, if = the outer header’s PCN-marking is more severe than the inner IP header’s, then copy it to the inner IP header.

At least I think the Uniform model = is best for the normal (?) case where the tunnel is within the PCN-domain = – because we want all nodes in the PCN-domain to be able potentially to = PCN-mark & hence contribute to the adm ctrl decisions. If the tunnel is = partly within a PCN-domain and partly outside I think the uniform model is = still the right one (not too sure – there are lots of things complicating = it, some of which mentioned in first email below, but I think the conceptual = model should still be the same].

 

Ruediger: question about what you = call ‘downpropagation’, I assume this is the copying operation I = refer to in the Uniform model. I agree with you for PCN marking [text is = already in the archit draft on these lines]. However, you also mention = downpropagation of DSCP which I don’t think is correct.

 

Ruediger, you mention where the = DSCP values have different meanings at the tunnel ingress & egress = (tunnel crosses a diffserv domain boundary). Yes, I believe this is a general = diffserv issue and is covered by 2475.

 

phil

 

-----Original Message-----
From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]
Sent: 24 October 2007 = 12:10
To: = Eardley,PL,Philip,CXR9 R
Cc: pcn@ietf.org
Subject: RE: [PCN] PCN = & tunnelling

 

Phil,

 

I guess this is a general DiffServ = issue too. In case [2] you assume the same DSCP to be used by the tunnel = end point PCN domain as at the tunnel entry. This assumption may not hold, = if the set DSCP is used for another service class or unused at the end = point.

 

I had a brief glance on RFC2983, "Differentiated Services and Tunnels". Downpropagation of = outer IP header DSCP/PCN settings may be a fairly good = recommendation.

 

Regards,

 

Rudiger

-----Original = Message-----
From: = philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: Wednesday, October = 24, 2007 12:24 PM
To: pcn@ietf.org
Subject: [PCN] PCN & tunnelling

Hi,

 

I was chatting with Bob about section 5.8 tunnelling. = We’ve realised there’s the following nasty case which we hadn’t = thought about. The scenario is when a tunnel starts inside a PCN-domain and = finishes outside it.

 

First we follow what happens when the current text is followed. = Imagine that the pkt is PCN-marked by some PCN-node before the tunnel start = node. On encapsulation the PCN-mark is copied onto the outer header. Hence the PCN-egress-node ‘sees’ the PCN-mark as normal – this = is ok. The PCN-egress-node clears the marking in the (outer) header and = forwards the pkt into the next domain. The pkt is decapsulated at the tunnel end = point. But the decapsulated pkt is already PCN-marked. Potential problems: [1] if it’s decapsulated in a non-PCN-domain, then the pkt may confuse = nodes in this domain [depending on what encoding is used for a PCN-mark] ; [2] if it’s decapsulated in a PCN-domain, then the pkt is PCN-marked = [which might lead this PCN-domain to terminate or block a flow = unnecessarily].

 

The problem arises because the PCN-egress-node clears = PCN-marking on the outer header but not on the inner header. (This is a new problem = compared with ECN & tunnelling.)

 

Possible solution: if the pkt is PCN-marked, then the tunnel = start node checks whether the tunnel egress is inside or outside the PCN-domain - = if it’s outside, then it clears the PCN-marking on the inner header (effectively it does this on behalf of the PCN-egress-node). (Also, the PCN-mark is copied onto the outer header, as the current text = says.)

 

Thoughts?

 

Thanks,

Phil/  

=00 ------_=_NextPart_001_01C816F3.85468EBF-- --===============1364694787== 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 --===============1364694787==-- From pcn-bounces@ietf.org Thu Oct 25 06:51:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il0J0-0000MZ-Ex; Thu, 25 Oct 2007 06:51:14 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Il0Iz-0000MS-E6 for pcn-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 06:51:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il0Iz-0000MH-3h for pcn@ietf.org; Thu, 25 Oct 2007 06:51:13 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Il0Is-0007mW-4Q for pcn@ietf.org; Thu, 25 Oct 2007 06:51:13 -0400 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Thu, 25 Oct 2007 12:50:59 +0200 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Oct 2007 12:50:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PCN] PCN & tunnelling Date: Thu, 25 Oct 2007 12:50:58 +0200 Message-Id: <1B6169C658325341A3B8066E23919E1C4C1331@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC5FA@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN & tunnelling thread-index: AcgWJ+54M2I8eYc4QJu/kWUfuySz/QABQXZQAA2JTqAAIfRrQAAApIIgAAG41BA= From: "Geib, Ruediger" To: X-OriginalArrivalTime: 25 Oct 2007 10:50:59.0396 (UTC) FILETIME=[ED969840:01C816F4] X-Spam-Score: -1.0 (-) X-Scan-Signature: 20c6ed26ee4f226a67d90641b17dfc32 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1103193523==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1103193523== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C816F4.ED1C4EB1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C816F4.ED1C4EB1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Phil, =20 yes to your main conclusions. I also think we should not recommend to = start tunnels within a PCN domain which end in the midlle of another one = (especially, if this was breaking the single PCN domain assumption ;-). =20 Regards, =20 Rudiger -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: Thursday, October 25, 2007 12:41 PM To: Geib, R=FCdiger Cc: pcn@ietf.org Subject: RE: [PCN] PCN & tunnelling I'm going to leave commenting on the DSCP stuff to diffserv experts. = Anyway, I assume the answer is "whatever happens in a diffserv network" = - I don't see why the existence of PCN would make any odds. =20 Your other point is about what happens if the tunnel egress is at the = PCN-egress-node. I agree with the basic point I think you're making, = that there's no need for the copying operations when the tunnel egress = is at the PCN-egress-node - or indeed when the tunnel ingress is at the = PCN-ingress-node. Ie the values specific to the pcn-domain shouldn't be = used outside. However I don't think your method necessarily works - for = instance if the tunnel starts inside the PCN-domain - the = PCN-egress-node still needs to do PCN-colouring ie sets the dscp & ecn = fields to the values appropriate for use in the next domain =20 =20 Another way of looking at this (I think) is that tunnel ingress = functions are done before PCN-ingress-node functions, and tunnel egress = functions are done after PCN-egress functions does its PCN-metering = function but before its PCN-colouring function.=20 =20 Phil/=20 =20 =20 -----Original Message----- From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]=20 Sent: 25 October 2007 10:48 To: Eardley,PL,Philip,CXR9 R Cc: pcn@ietf.org Subject: RE: [PCN] PCN & tunnelling =20 Phil, =20 by propagating down DSCP and PCN settings at a tunnel end, a router can = make sure that the next hop is able to correctly interpret these values = - if this next hop is within its own domain. If the tunnel end is an = edge router and the next hop is part of a different domain, then the = edge router should neither change the inner header DSCP nor the PCN = codepoints. Is that what you think of? =20 Regards, =20 Rudiger -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: Wednesday, October 24, 2007 9:07 PM To: Geib, R=FCdiger Cc: pcn@ietf.org Subject: RE: [PCN] PCN & tunnelling Ruediger, =20 Yes, it is a more general problem. I've been trying to read 2983 = [diffserv & tunnels] and 3270 [mpls & diffserv - similar kinds of = issues] =20 2983 has 2 conceptual models, Uniform & Pipe: - Uniform: tunnel is an artefact on the e2e path from a traffic = conditioning viewpoint; pkt effectively has one DS field that's used for = traffic conditioning. Copy DSCP value to the outer header at encaps and = copy outer header's dscp value to inner IP header at decaps.=20 - Pipe: IP tunnel hides the nodes so they don't really participate in = traffic conditioning. Tunnel egress ignores the outer header's dscp & = uses the inner header's DSCP (or rather the traffic conditioning info it = conveys - to cover the case where the same meaning is encoded by = different values of dscp). Tunnel links DS domains at end points into a = diffserv region ('virtually' contiguous).=20 =20 When it comes to PCN & tunnels, something analogous to the Uniform model = seems more appropriate to me - ie the pkt effectively has one field for = PCN-marking that's used for PCN-based adm ctrl (& termination); the = operation is at decaps, if the outer header's PCN-marking is more severe = than the inner IP header's, then copy it to the inner IP header.=20 At least I think the Uniform model is best for the normal (?) case where = the tunnel is within the PCN-domain - because we want all nodes in the = PCN-domain to be able potentially to PCN-mark & hence contribute to the = adm ctrl decisions. If the tunnel is partly within a PCN-domain and = partly outside I think the uniform model is still the right one (not too = sure - there are lots of things complicating it, some of which mentioned = in first email below, but I think the conceptual model should still be = the same].=20 =20 Ruediger: question about what you call 'downpropagation', I assume this = is the copying operation I refer to in the Uniform model. I agree with = you for PCN marking [text is already in the archit draft on these = lines]. However, you also mention downpropagation of DSCP which I don't = think is correct.=20 =20 Ruediger, you mention where the DSCP values have different meanings at = the tunnel ingress & egress (tunnel crosses a diffserv domain boundary). = Yes, I believe this is a general diffserv issue and is covered by 2475. =20 phil =20 -----Original Message----- From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]=20 Sent: 24 October 2007 12:10 To: Eardley,PL,Philip,CXR9 R Cc: pcn@ietf.org Subject: RE: [PCN] PCN & tunnelling =20 Phil, =20 I guess this is a general DiffServ issue too. In case [2] you assume the = same DSCP to be used by the tunnel end point PCN domain as at the tunnel = entry. This assumption may not hold, if the set DSCP is used for another = service class or unused at the end point.=20 =20 I had a brief glance on RFC2983, "Differentiated Services and Tunnels". = Downpropagation of outer IP header DSCP/PCN settings may be a fairly = good recommendation. =20 Regards, =20 Rudiger -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: Wednesday, October 24, 2007 12:24 PM To: pcn@ietf.org Subject: [PCN] PCN & tunnelling Hi, =20 I was chatting with Bob about section 5.8 tunnelling. We've realised = there's the following nasty case which we hadn't thought about. The = scenario is when a tunnel starts inside a PCN-domain and finishes = outside it.=20 =20 First we follow what happens when the current text is followed. Imagine = that the pkt is PCN-marked by some PCN-node before the tunnel start = node. On encapsulation the PCN-mark is copied onto the outer header. = Hence the PCN-egress-node 'sees' the PCN-mark as normal - this is ok. = The PCN-egress-node clears the marking in the (outer) header and = forwards the pkt into the next domain. The pkt is decapsulated at the = tunnel end point. But the decapsulated pkt is already PCN-marked. = Potential problems: [1] if it's decapsulated in a non-PCN-domain, then = the pkt may confuse nodes in this domain [depending on what encoding is = used for a PCN-mark] ; [2] if it's decapsulated in a PCN-domain, then = the pkt is PCN-marked [which might lead this PCN-domain to terminate or = block a flow unnecessarily]. =20 The problem arises because the PCN-egress-node clears PCN-marking on the = outer header but not on the inner header. (This is a new problem = compared with ECN & tunnelling.)=20 =20 Possible solution: if the pkt is PCN-marked, then the tunnel start node = checks whether the tunnel egress is inside or outside the PCN-domain - = if it's outside, then it clears the PCN-marking on the inner header = (effectively it does this on behalf of the PCN-egress-node). (Also, the = PCN-mark is copied onto the outer header, as the current text says.) =20 Thoughts? =20 Thanks, Phil/ =20 ------_=_NextPart_001_01C816F4.ED1C4EB1 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Phil,
 
yes to=20 your main conclusions. I also think we should not recommend to start = tunnels=20 within a PCN domain which end in the midlle of another one (especially, = if this=20 was breaking the single PCN domain assumption ;-).
 
Regards,
 
Rudiger
-----Original Message-----
From: = philip.eardley@bt.com=20 [mailto:philip.eardley@bt.com]
Sent: Thursday, October 25, = 2007=20 12:41 PM
To: Geib, R=FCdiger
Cc:=20 pcn@ietf.org
Subject: RE: [PCN] PCN &=20 tunnelling

I’m = going to leave=20 commenting on the DSCP stuff to diffserv experts. Anyway, I assume the = answer=20 is “whatever happens in a diffserv network” – I = don’t see why the existence of=20 PCN would make any odds.

 

Your other = point is=20 about what happens if the tunnel egress is at the PCN-egress-node. I = agree=20 with the basic point I think you’re making, that there’s = no need for the=20 copying operations when the tunnel egress is at the PCN-egress-node = – or=20 indeed when the tunnel ingress is at the PCN-ingress-node. Ie the = values=20 specific to the pcn-domain = shouldn’t be=20 used outside. However I don’t think your method necessarily = works - for=20 instance if the tunnel starts inside the PCN-domain – the = PCN-egress-node=20 still needs to do PCN-colouring ie sets the dscp & ecn fields to = the=20 values appropriate for use in the next domain  

 

Another way = of=20 looking at this (I think) is that tunnel ingress functions are done = before=20 PCN-ingress-node functions, and tunnel egress functions are done after = PCN-egress functions does its PCN-metering function but before its=20 PCN-colouring function.

 

Phil/=20

 

 

-----Original=20 Message-----
From: = Geib,=20 Ruediger [mailto:Ruediger.Geib@t-systems.com]
Sent: 25=20 October 2007 10:48
To: Eardley,PL,Philip,CXR9 = R
Cc: pcn@ietf.org
Subject: RE: [PCN] PCN &=20 tunnelling

 

Phil,

 

by = propagating down=20 DSCP and PCN settings at a tunnel end, a router can make sure = that the=20 next hop is able to correctly interpret these values - if this next = hop is=20 within its own domain. If the tunnel end is an edge router and the = next hop is=20 part of a different domain, then the edge router should neither change = the=20 inner header DSCP nor the PCN codepoints. Is that what you think=20 of?

 

Regards,

 

Rudiger

-----Original=20 Message-----
From:=20 philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: Wednesday, October 24, = 2007 9:07=20 PM
To: Geib,=20 R=FCdiger
Cc:=20 pcn@ietf.org
Subject: RE:=20 [PCN] PCN & tunnelling

Ruediger,

 

Yes, it = is a more=20 general problem. I’ve been trying to read 2983 [diffserv & = tunnels] and=20 3270 [mpls & diffserv – similar kinds of = issues]

 

2983 has = 2=20 conceptual models, Uniform & Pipe:

- = Uniform: tunnel=20 is an artefact on the e2e path from a traffic conditioning = viewpoint; pkt=20 effectively has one DS field that’s used for traffic = conditioning. Copy DSCP=20 value to the outer header at encaps and copy outer header’s = dscp value to=20 inner IP header at decaps.

- Pipe: = IP tunnel=20 hides the nodes so they don’t really participate in traffic = conditioning.=20 Tunnel egress ignores the outer header’s dscp & uses the = inner header’s=20 DSCP (or rather the traffic conditioning info it conveys – to = cover the case=20 where the same meaning is encoded by different values of dscp). = Tunnel links=20 DS domains at end points into a diffserv region = (‘virtually’ contiguous).=20

 

When it = comes to=20 PCN & tunnels, something analogous to the Uniform model seems = more=20 appropriate to me – ie the pkt effectively has one field for = PCN-marking=20 that’s used for PCN-based adm ctrl (& termination); the = operation is at=20 decaps, if the outer header’s PCN-marking is more severe than = the inner IP=20 header’s, then copy it to the inner IP header. =

At least = I think=20 the Uniform model is best for the normal (?) case where the tunnel = is within=20 the PCN-domain – because we want all nodes in the PCN-domain = to be able=20 potentially to PCN-mark & hence contribute to the adm ctrl = decisions. If=20 the tunnel is partly within a PCN-domain and partly outside I think = the=20 uniform model is still the right one (not too sure – there are = lots of=20 things complicating it, some of which mentioned in first email = below, but I=20 think the conceptual model should still be the same]. =

 

Ruediger: = question=20 about what you call ‘downpropagation’, I assume this is = the copying=20 operation I refer to in the Uniform model. I agree with you for PCN = marking=20 [text is already in the archit draft on these lines]. However, you = also=20 mention downpropagation of DSCP which I don’t think is = correct.=20

 

Ruediger, = you=20 mention where the DSCP values have different meanings at the tunnel = ingress=20 & egress (tunnel crosses a diffserv domain boundary). Yes, I = believe=20 this is a general diffserv issue and is covered by = 2475.

 

phil

 

-----Original=20 Message-----
From: Geib,=20 Ruediger [mailto:Ruediger.Geib@t-systems.com]
Sent: 24 October 2007 = 12:10
To: Eardley,PL,Philip,CXR9=20 R
Cc:=20 pcn@ietf.org
Subject: RE:=20 [PCN] PCN & tunnelling

 

Phil,

 

I guess = this is a=20 general DiffServ issue too. In case [2] you assume the same DSCP to = be used=20 by the tunnel end point PCN domain as at the tunnel entry. This = assumption may not hold, if the set DSCP is used for another = service=20 class or unused at the end point.

 

I had a = brief=20 glance on RFC2983, "Differentiated Services and Tunnels". = Downpropagation of=20 outer IP header DSCP/PCN settings may be a fairly good=20 recommendation.

 

Regards,

 

Rudiger

-----Original=20 Message-----
From:=20 philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: Wednesday, October = 24, 2007=20 12:24 PM
To:=20 pcn@ietf.org
Subject:=20 [PCN] PCN & tunnelling

Hi,

 

I was chatting with Bob about section = 5.8=20 tunnelling. We’ve realised there’s the following nasty = case which we=20 hadn’t thought about. The scenario is when a tunnel starts = inside a=20 PCN-domain and finishes outside it.

 

First we follow what happens when the = current text=20 is followed. Imagine that the pkt is PCN-marked by some PCN-node = before=20 the tunnel start node. On encapsulation the PCN-mark is copied = onto the=20 outer header. Hence the PCN-egress-node ‘sees’ the = PCN-mark as normal –=20 this is ok. The PCN-egress-node clears the marking in the (outer) = header=20 and forwards the pkt into the next domain. The pkt is decapsulated = at the=20 tunnel end point. But the decapsulated pkt is already PCN-marked.=20 Potential problems: [1] if it’s decapsulated in a = non-PCN-domain, then the=20 pkt may confuse nodes in this domain [depending on what encoding = is used=20 for a PCN-mark] ; [2] if it’s decapsulated in a PCN-domain, = then the pkt=20 is PCN-marked [which might lead this PCN-domain to terminate or = block a=20 flow unnecessarily].

 

The problem arises because the = PCN-egress-node=20 clears PCN-marking on the outer header but not on the inner = header. (This=20 is a new problem compared with ECN & tunnelling.) =

 

Possible solution: if the pkt is = PCN-marked, then=20 the tunnel start node checks whether the tunnel egress is inside = or=20 outside the PCN-domain - if it’s outside, then it clears the = PCN-marking=20 on the inner header (effectively it does this on behalf of the=20 PCN-egress-node). (Also, the PCN-mark is copied onto the outer = header, as=20 the current text says.)

 

Thoughts?

 

Thanks,

Phil/=20 =  

------_=_NextPart_001_01C816F4.ED1C4EB1-- --===============1103193523== 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 --===============1103193523==-- From pcn-bounces@ietf.org Thu Oct 25 06:56:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il0OI-0007yu-5R; Thu, 25 Oct 2007 06:56:42 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Il0OH-0007yp-94 for pcn-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 06:56:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il0OG-0007yg-Ua for pcn@ietf.org; Thu, 25 Oct 2007 06:56:40 -0400 Received: from smtp3.smtp.bt.com ([217.32.164.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Il0OG-000312-HC for pcn@ietf.org; Thu, 25 Oct 2007 06:56:40 -0400 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.63]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Oct 2007 11:56:39 +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] Architecture draft - probing section & general updates. Date: Thu, 25 Oct 2007 11:56:38 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC5FC@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <9EE2BE22-5E19-4625-B368-3A603728ED52@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Architecture draft - probing section & general updates. Thread-Index: AcgW7Vwus3tUSdCIRHq1ll0tgHrrfwAB8PQw From: To: , X-OriginalArrivalTime: 25 Oct 2007 10:56:39.0619 (UTC) FILETIME=[B8608130:01C816F5] X-Spam-Score: -1.0 (-) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: pcn@ietf.org, Ruediger.Geib@t-systems.com X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Lars, I believe the guess is that there'll be many ingress-egress pairs with none or very few flows at a particular moment. Not a random distribution of calls onto all possible pairs. Basically there are many calls between London & Manchester and very few between truro and Shetland. I & Ben will try and extract some numbers from the [bt] predicted future traffic matrix. -----Original Message----- From: Lars Eggert [mailto:lars.eggert@nokia.com]=20 Sent: 25 October 2007 10:54 To: ext Jozef Babiarz Cc: pcn@ietf.org; Geib, Ruediger Subject: Re: [PCN] Architecture draft - probing section & general updates. On 2007-10-24, at 19:14, ext Jozef Babiarz wrote: > I'm thinking of a scenario that many enterprises face today. Large =20 > multi > location enterprises use multiple WAN links or VPS to interconnect =20 > their > locations. PCN is run inside the enterprise network including WAN =20 > links > which maybe tunneled across the carrier network. Network Access =20 > Control > with PCN admission control is done at the enterprise access edge =20 > nodes. > New flows can be routed to any egress access edge node and some flows > will (between different locations) be routed over one of the WAN links > which are normally bandwidth constrained. I understand your scenario so far. > There is a high probability > that many access nodes will only have one flow between each other as > there are a large number of them. I don't see how this follows, however. It seems that if the sites =20 that are being interconnected aren't tiny, there should very likely =20 be multiple flows per ingress/egress pair, no? Lars _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Oct 25 07:38:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il12Q-0004cI-1N; Thu, 25 Oct 2007 07:38:10 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Il12O-0004bj-L8 for pcn-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 07:38:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il12O-0004ap-6z for pcn@ietf.org; Thu, 25 Oct 2007 07:38:08 -0400 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Il12J-0003ux-Fa for pcn@ietf.org; Thu, 25 Oct 2007 07:38:04 -0400 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.63]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Oct 2007 12:36:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 25 Oct 2007 12:36:36 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC5FE@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: new text about Tunnelling for architecture draft Thread-Index: AcgW+0zEw+jXMppFTPiVcZ1Yb6Dn3w== From: To: X-OriginalArrivalTime: 25 Oct 2007 11:36:38.0459 (UTC) FILETIME=[4E3270B0:01C816FB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6379955759c38e2371a49573a0932fc7 Subject: [PCN] new text about Tunnelling for architecture draft X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1412565482==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1412565482== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C816FB.4CE8F0FD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C816FB.4CE8F0FD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Have tried to re-write the tunnelling section in the architecture draft to reflect the recent emails: =20 Tunnelling (modified text for S5.8) Tunnels may originate and/or terminate within a PCN-domain. It is important that the PCN-marking of any packet can potentially influence PCN's flow admission control and termination - it shouldn't matter whether the packet happens to be tunnelled at the PCN-node that PCN-marks the packet, or indeed whether it's decapsulated or encapsulated by a subsequent PCN-node.=20 =20 This suggests that the "uniform conceptual model" described in [2983] should be re-applied in the PCN context. In line with this and the approach of [4303] and [draft-briscoe-tsvwg-ecn-tunnel], the following rule is applied if encapsulation is done within the PCN-domain: * any PCN-marking is copied into the outer header =20 =20 Similarly, in line with the "uniform conceptual model" of [2983] and the "full-functionality option" of [3168], the following rules are applied if decapsulation is done within the PCN-domain: * if the outer header's marking state is more severe then it is copied onto the inner header * NB the order of increasing severity is: unmarked; PCN-marking with first encoding (ie associated with the PCN-lower-rate); PCN-marking with second encoding (ie associated with the PCN-upper-rate) =20 The essential reason for the copying operations described above is to simplify dealing with the various headers: PCN-marking is then orthogonal to tunnel encapsulation /decapsulation.=20 =20 An operator may wish to tunnel PCN-traffic from PCN-ingress-nodes to PCN-egress-nodes. The PCN-marks shouldn't be visible outside the PCN-domain, which can be achieved by PCN-colouring (Section 5.3) after all the other functions. The potential reasons for doing such tunnelling are: the PCN-egress-node then automatically knows the address of the relevant PCN-ingress-node for a flow; even if ECMP is running, all PCN-packets on a particular ingress-egress-aggregate follow the same path. But it also has drawbacks, for example the additional overhead in terms of bandwidth and processing.=20 =20 Open issues: (text for S6, second para is new) Tunnelling: There are scenarios where tunnelling makes it hard to determine the path in the PCN-domain. The problem, its impact and the potential solutions are similar to those for ECMP.=20 =20 Partially PCN-capable tunnels: (1) The tunnel starts outside a PCN-domain and finishes inside it. If the packet arrives at the tunnel ingress with the same encoding as used within the PCN-domain to indicate PCN-marking, then this could lead the PCN-egress-node to falsely measure pre-congestion. (2) The tunnel starts inside a PCN-domain and finishes outside it. If the packet arrives at the tunnel ingress already PCN-marked, then it will still have the same encoding when it's decapsulated which could potentially confuse nodes beyond the tunnel egress. (3) Scenarios with partially PCN-capable tunnels may also make it harder for the PCN-egress-node to gather from the signalling messages (eg RSVP, NSIS) the identity of the PCN-ingress-node.=20 =20 =20 Potential solutions: (out of scope of architecture draft, but I'll add a ref to this email thread) * tunnel starts outside a PCN-domain and finishes inside it: could require tunnel egress to drop such a packet. This is same approach as in S3.5, where PCN-ingress-node drops packet. * tunnel starts inside a PCN-domain and finishes outside it: could require the tunnel ingress to check (somehow) whether the tunnel egress is outside the PCN-domain, and if it is then clear any PCN-marking on the inner header. * Signalling and partially-capable PCN-tunnels: don't know, could try something similar to nsis [rfc4080 S5.4]: < To signal for the packets carrying the tunneled data, the tunnel is considered a new data flow in its own right, and NSIS signaling is applied to it recursively. This requires signaling support in at least one tunnel endpoint.> This problem should be considered in the milestone doc about reqts for pcn signalling.=20 =20 =20 ------_=_NextPart_001_01C816FB.4CE8F0FD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Have tried to re-write the tunnelling section = in the architecture draft to reflect the recent emails:

 

Tunnelling (modified text for S5.8)

Tunnels may originate and/or terminate within a PCN-domain. It = is important that the PCN-marking of any packet can potentially influence PCN’s flow admission control and termination – it = shouldn’t matter whether the packet happens to be tunnelled at the PCN-node that PCN-marks the packet, or indeed whether it’s decapsulated or = encapsulated by a subsequent PCN-node.

 

This suggests that the “uniform conceptual model” = described in [2983] should be re-applied in the PCN context. In line with this and = the approach of [4303] and [draft-briscoe-tsvwg-ecn-tunnel], = the following rule is applied if encapsulation is done within the = PCN-domain:

·        any PCN-marking is copied into the outer = header   

 

Similarly, in line with the “uniform conceptual = model” of [2983] and the “full-functionality option” of [3168], the = following rules are applied if decapsulation is done within the = PCN-domain:

·        if the outer header's marking state is more = severe then it is copied onto the inner header

·        NB the order of increasing severity is: = unmarked; PCN-marking with first encoding (ie associated with the PCN-lower-rate); PCN-marking with second encoding (ie associated with the = PCN-upper-rate)

 

The essential reason for the copying operations described above = is to simplify dealing with the various headers: PCN-marking is then = orthogonal to tunnel encapsulation /decapsulation.

 

An operator may wish to tunnel PCN-traffic from = PCN-ingress-nodes to PCN-egress-nodes. The PCN-marks shouldn’t be visible outside the = PCN-domain, which can be achieved by PCN-colouring (Section 5.3) after all the other functions. The potential reasons for doing such tunnelling are: the PCN-egress-node then automatically knows the address of the relevant PCN-ingress-node for a flow; even if ECMP is running, all PCN-packets on = a particular ingress-egress-aggregate follow the same path. But it also = has drawbacks, for example the additional overhead in terms of bandwidth and processing.

 

Open issues: (text for S6, second para is new)

Tunnelling: There are scenarios where tunnelling makes it hard = to determine the path in the PCN-domain. The problem, its impact and the = potential solutions are similar to those for ECMP.

 

Partially PCN-capable tunnels: (1) The tunnel starts outside a PCN-domain and finishes inside it. If the packet arrives at the tunnel = ingress with the same encoding as used within the PCN-domain to indicate PCN-marking, = then this could lead the PCN-egress-node to falsely measure = pre-congestion.  (2) The tunnel starts inside a PCN-domain and finishes outside it. If the packet arrives at the tunnel ingress already PCN-marked, then it will still = have the same encoding when it’s decapsulated which could potentially = confuse nodes beyond the tunnel egress.  (3) Scenarios with partially = PCN-capable tunnels may also make it harder for the PCN-egress-node to gather from = the signalling messages (eg RSVP, NSIS) the identity of the = PCN-ingress-node.

 

 

Potential solutions: (out of scope of architecture draft, but I’ll add a ref to this email thread)

·        tunnel starts outside a PCN-domain and = finishes inside it: could require tunnel egress to drop such a packet. This is = same approach as in S3.5, where PCN-ingress-node drops packet.

·        tunnel starts inside a PCN-domain and = finishes outside it: could require the tunnel ingress to check (somehow) whether = the tunnel egress is outside the PCN-domain, and if it is then clear any PCN-marking on the inner header.

·        Signalling and partially-capable = PCN-tunnels: don’t know, could try something similar to nsis [rfc4080 S5.4]: = < To signal for the packets carrying the tunneled data, the tunnel is = considered a new data flow in its own right, and NSIS signaling is applied to it recursively.  This requires signaling support in at least one = tunnel endpoint.> This problem should be considered in the milestone doc = about reqts for pcn signalling.

 

 

=00 ------_=_NextPart_001_01C816FB.4CE8F0FD-- --===============1412565482== 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 --===============1412565482==-- From pcn-bounces@ietf.org Thu Oct 25 08:04:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il1Rx-0005oz-9J; Thu, 25 Oct 2007 08:04:33 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Il1Rw-0005os-Ay for pcn-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 08:04:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il1Rv-0005ok-Ll for pcn@ietf.org; Thu, 25 Oct 2007 08:04:31 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Il1Ro-0001FQ-7D for pcn@ietf.org; Thu, 25 Oct 2007 08:04:31 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9PC4DKP021183 for ; Thu, 25 Oct 2007 15:04:18 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Oct 2007 15:03:46 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Oct 2007 15:03:46 +0300 Received: from [172.21.35.48] (esdhcp03548.research.nokia.com [172.21.35.48]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9PC3i3m020421 for ; Thu, 25 Oct 2007 15:03:44 +0300 Mime-Version: 1.0 (Apple Message framework v752.3) To: pcn@ietf.org Message-Id: <75FEE0DB-D9D7-4738-A68A-E816D08B03C7@nokia.com> From: Lars Eggert Date: Tue, 23 Jan 2007 17:15:18 +0200 X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 25 Oct 2007 12:03:46.0234 (UTC) FILETIME=[186D31A0:01C816FF] X-Nokia-AV: Clean X-Spam-Score: 2.3 (++) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Subject: [PCN] charter update X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1365258119==" Errors-To: pcn-bounces@ietf.org --===============1365258119== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-8-132073995; protocol="application/pkcs7-signature" --Apple-Mail-8-132073995 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, as mentioned previously, I have edited the charter proposal posted to this list in December to reflect the discussions that have occurred on- and off-list. The main changes are a removal of the SIP, application-based and pseudowire deployment scenarios, a restructuring of the initial deliverables and milestones, and a set of stronger retrictions. Please send comments! Lars Description of Working Group: The Flow Admission and Preemption (FLAP) working group develops flow admission and flow preemption mechanisms for deployment along the edge of a network domain that protect the quality-of-service that previously-admitted flows experience within the domain during times of congestion. These mechanisms act on aggregated congestion and pre- congestion signals from routers within the network domain and control the admission of new flows into the domain or preempt previously- admitted flows. Although designed to work together, flow admission and flow preemption are independent mechanisms, and the use of one does not require the use of the other. The FLAP WG will specify the following components of an integrated flow admission and preemption mechanism: (1) a general architecture for flow admission and preemption based on aggregated (pre-)congestion signals (2) conditions under which interior routers generate (pre-)congestion signals (3) encoding and transport of (pre-)congestion signals to the appropriate ingress routers of the network domain (4) edge router control mechanisms for flow admission and preemption based on aggregated (pre-)congestion information The WG focuses on the overall architecture and specifically the signaling interfaces needed to realize it. Standards-track protocols are only developed when necessary for interoperability. When algorithms are not necessary for interoperability the WG may document examples or provide recommended solutions, however such work should not be done at the expense of normative specifications. The initial scope of the FLAP WG is restricted in the following ways: (A) develop these components for a single DiffServ region, where all edge and interior routers are FLAP-enabled and mutually trust each other (B) all flows handled by these mechanisms are inelastic and constrained to a known maximum rate through policing or shaping (C) the number of flows across any potential aggregation bottleneck is sufficiently large for stateless, statistical mechanisms to be effective (D) aggregation occurs either on links or ingress/egress pairs; mechanisms must further define relevant limits (E) flows may have different precedence, but the applicability of these mechanisms for emergency use (911, GETS, WPS, MLPP, etc.) is out of scope After completion of the initial phase, the FLAP WG may recharter to develop solutions for scenarios where some of these restrictions are not in place. It may also recharter to consider applying the FLAP mechanisms to additional deployment scenarios (operation over concatenated DiffServ regions, FLAP-aware application mechanisms, etc.). The WG may also consider to investigate additional response mechanisms that act on (pre-)congestion signals. One example could be flow-rate adaptation (rather than flow admission/preemption) during times of congestion. The details of these work items are outside the scope of the initial phase; but the WG may want to However in the initial scope this mechanism is out-of-scope with the exception that the developed solution should not, if possible, prevent a future evolution to support this. Goals and Milestones: Jul 2007 Flow Admission and Preemption Architecture (Informational) Jul 2007 Survey of Encoding and Transport Choices of (Pre-)Congestion Signals within a DiffServ Region (Informational) Nov 2007 Flow Admission and Preemption within a DiffServ Region (Informational) Nov 2007 (Pre-)Congestion Detection within a DiffServ Region (Proposed Standard) Mar 2008 Encoding and Transport of (Pre-)Congestion Signals within a DiffServ Region to Flow Egress (Proposed Standard) Mar 2008 Transport from Flow Egress in a DiffServ Region of information (possibly aggregated) or Admission/Preemption Signals to DiffServ edge devices. (Proposed Standard) Mar 2008 Suggested Flow Admission and Preemption Edge Mechanisms (Informational) --Apple-Mail-8-132073995 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzAxMjMxNTE1MTlaMCMGCSqGSIb3DQEJBDEWBBQaHzFaP4THnhUU IunIV4O/sC193jCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAwtCHtJIruNOh5vaV3NU+4z625dwW/j8j9M4y9ITtbEYtmSfhasW9 sf7uU6SsmMKfRvJQABDMPLKaqeCbFbXRLMTAiqIaNSe2OMDsKylIC00RqQO1ha13yXdyVajd+7gQ bUCAbj9wVCsC4a4/0wFSUgCK4fcpoadxIahLuQkfVnfZwVmay5WYSltLQgFH27j4R4eIdbYD1mCM 8S6HsSNFrOfv0mQi9SrUJ2+hpPOELvbURaAHzX0+cNiQK3ciruBgxzb3dVRoLwqC6NFytH10VE92 Ajpv5LdLxbNrnwwixog6W9ePoud8Ijw/8ypqbu54DpWyONqTP/Bozu5MOQootAAAAAAAAA== --Apple-Mail-8-132073995-- --===============1365258119== 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 --===============1365258119==-- From pcn-bounces@ietf.org Thu Oct 25 08:17:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il1dS-000484-4Y; Thu, 25 Oct 2007 08:16:26 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Il1dQ-000472-P3 for pcn-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 08:16:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il1dQ-00043Q-4d for pcn@ietf.org; Thu, 25 Oct 2007 08:16:24 -0400 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Il1dK-0004oF-86 for pcn@ietf.org; Thu, 25 Oct 2007 08:16:18 -0400 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.63]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Oct 2007 13:16:17 +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] charter update Date: Thu, 25 Oct 2007 13:16:16 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC600@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <75FEE0DB-D9D7-4738-A68A-E816D08B03C7@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] charter update Thread-Index: AcgW/6G6sBHpHUkESlKnZPBWkdDHQgAAN9Zw From: To: , X-OriginalArrivalTime: 25 Oct 2007 12:16:17.0090 (UTC) FILETIME=[D7F8BA20:01C81700] X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org A quick first one - any chance of sticking with 'termination'? I just got used to it rather than pre-emption! [I know FLAP is more amusing than FLAT...] phil -----Original Message----- From: Lars Eggert [mailto:lars.eggert@nokia.com]=20 Sent: 23 January 2007 15:15 To: pcn@ietf.org Subject: [PCN] charter update Hi, as mentioned previously, I have edited the charter proposal posted to =20 this list in December to reflect the discussions that have occurred =20 on- and off-list. The main changes are a removal of the SIP, =20 application-based and pseudowire deployment scenarios, a =20 restructuring of the initial deliverables and milestones, and a set =20 of stronger retrictions. Please send comments! Lars Description of Working Group: The Flow Admission and Preemption (FLAP) working group develops flow =20 admission and flow preemption mechanisms for deployment along the =20 edge of a network domain that protect the quality-of-service that =20 previously-admitted flows experience within the domain during times =20 of congestion. These mechanisms act on aggregated congestion and pre-=20 congestion signals from routers within the network domain and control =20 the admission of new flows into the domain or preempt previously-=20 admitted flows. Although designed to work together, flow admission =20 and flow preemption are independent mechanisms, and the use of one =20 does not require the use of the other. The FLAP WG will specify the following components of an integrated =20 flow admission and preemption mechanism: (1) a general architecture for flow admission and preemption based on aggregated (pre-)congestion signals (2) conditions under which interior routers generate (pre-)congestion signals (3) encoding and transport of (pre-)congestion signals to the appropriate ingress routers of the network domain (4) edge router control mechanisms for flow admission and preemption based on aggregated (pre-)congestion information The WG focuses on the overall architecture and specifically the =20 signaling interfaces needed to realize it. Standards-track protocols =20 are only developed when necessary for interoperability. When =20 algorithms are not necessary for interoperability the WG may document =20 examples or provide recommended solutions, however such work should =20 not be done at the expense of normative specifications. The initial scope of the FLAP WG is restricted in the following ways: (A) develop these components for a single DiffServ region, where all edge and interior routers are FLAP-enabled and mutually trust each other (B) all flows handled by these mechanisms are inelastic and constrained to a known maximum rate through policing or shaping (C) the number of flows across any potential aggregation bottleneck is sufficiently large for stateless, statistical mechanisms =20 to be effective (D) aggregation occurs either on links or ingress/egress pairs; mechanisms must further define relevant limits (E) flows may have different precedence, but the applicability of these mechanisms for emergency use (911, GETS, WPS, MLPP, =20 etc.) is out of scope After completion of the initial phase, the FLAP WG may recharter to =20 develop solutions for scenarios where some of these restrictions are =20 not in place. It may also recharter to consider applying the FLAP =20 mechanisms to additional deployment scenarios (operation over =20 concatenated DiffServ regions, FLAP-aware application mechanisms, =20 etc.). The WG may also consider to investigate additional response =20 mechanisms that act on (pre-)congestion signals. One example could be =20 flow-rate adaptation (rather than flow admission/preemption) during =20 times of congestion. The details of these work items are outside the =20 scope of the initial phase; but the WG may want to However in the initial scope this mechanism is out-of-scope with the =20 exception that the developed solution should not, if possible, =20 prevent a future evolution to support this. Goals and Milestones: Jul 2007 Flow Admission and Preemption Architecture (Informational) Jul 2007 Survey of Encoding and Transport Choices of (Pre-)Congestion Signals within a DiffServ Region (Informational) Nov 2007 Flow Admission and Preemption within a DiffServ Region (Informational) Nov 2007 (Pre-)Congestion Detection within a DiffServ Region (Proposed Standard) Mar 2008 Encoding and Transport of (Pre-)Congestion Signals within a DiffServ Region to Flow Egress (Proposed Standard) Mar 2008 Transport from Flow Egress in a DiffServ Region of =20 information (possibly aggregated) or Admission/Preemption Signals to DiffServ edge devices. (Proposed Standard) Mar 2008 Suggested Flow Admission and Preemption Edge Mechanisms (Informational) _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Oct 25 08:25:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il1mO-0004R7-3o; Thu, 25 Oct 2007 08:25:40 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Il1mM-0004R0-Jm for pcn-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 08:25:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il1mM-0004Qs-6v for pcn@ietf.org; Thu, 25 Oct 2007 08:25:38 -0400 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 1Il1mK-0001l1-RW for pcn@ietf.org; Thu, 25 Oct 2007 08:25:38 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9PCPCVW018377; Thu, 25 Oct 2007 15:25:33 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Oct 2007 15:25:13 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh103.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Oct 2007 15:25:13 +0300 Received: from [172.21.35.48] (esdhcp03548.research.nokia.com [172.21.35.48]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9PCPBSC016940; Thu, 25 Oct 2007 15:25:12 +0300 In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC5FC@E03MVZ1-UKDY.domain1.systemhost.net> References: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC5FC@E03MVZ1-UKDY.domain1.systemhost.net> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: Lars Eggert Subject: Re: [PCN] Architecture draft - probing section & general updates. Date: Thu, 25 Oct 2007 15:25:07 +0300 To: "ext philip.eardley@bt.com" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 25 Oct 2007 12:25:13.0468 (UTC) FILETIME=[17AD83C0:01C81702] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: pcn@ietf.org, Ruediger.Geib@t-systems.com X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0333129041==" Errors-To: pcn-bounces@ietf.org --===============0333129041== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3-259543044; protocol="application/pkcs7-signature" --Apple-Mail-3-259543044 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-10-25, at 13:56, ext philip.eardley@bt.com wrote: > Lars, I believe the guess is that there'll be many ingress-egress > pairs > with none or very few flows at a particular moment. Not a random > distribution of calls onto all possible pairs. Basically there are > many > calls between London & Manchester and very few between truro and > Shetland. I can agree with that. But note that that alone is not a problem yet. The problem occurs only when several of these "empty" ingress pairs share a bottleneck *and* when single flows start simultaneously sending across them at a combined rate that will push the bottleneck directly into overload. I don't believe this can be very common. Wouldn't you provision your network such that interior routers could handle at least one flow per ingress/egress pair? In which case there is no issue unless there's a failure. And why not let flow termination handle these rare cases? > I & Ben will try and extract some numbers from the [bt] > predicted future traffic matrix. That'd be *very* useful! We're all guessing probabilities here, and data would help. Lars --Apple-Mail-3-259543044 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzEwMjUxMjI1MDhaMCMGCSqGSIb3DQEJBDEWBBSzjDGPca4WlrYy oCa8PmfoxzjIfTCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAVcV03lUt69q5bYKPntgdAp2O9BbLEiaUfBuAJehlvlBXD2r8T5oH iPuRHgTWBjpfuIYGf5bXBngREK8CjFXyF/wjFR3dEhRJVrfcQVmwDxOKoFHSlvpH3kgay3nSv+1M I9KActZIb5K30eO07aIvGcUuukBM46Zm9lUHkZz6hQ+Vu09n6479H3I4OdJb4WaPcbeJfo2DQZcY uu5KYkprRw8t+Km8ye7aDP1+Xh5BLmmPwLRFbOmGyp6EtNhz3roh+QJpC9sNn4jK43KS0IS/n5SZ OKCpsKaEMaC5JCejcYKrLbMa/a6YdsYgpki3fkwlxiIefOR1+mEhvPyojVYLbwAAAAAAAA== --Apple-Mail-3-259543044-- --===============0333129041== 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 --===============0333129041==-- From pcn-bounces@ietf.org Thu Oct 25 08:29:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il1qA-0006kF-AE; Thu, 25 Oct 2007 08:29:34 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Il1q8-0006hk-QQ for pcn-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 08:29:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il1q7-0006gP-2T for pcn@ietf.org; Thu, 25 Oct 2007 08:29:31 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Il1q5-0005EJ-UG for pcn@ietf.org; Thu, 25 Oct 2007 08:29:30 -0400 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 l9PCTNGr021791 for ; Thu, 25 Oct 2007 15:29:25 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Oct 2007 15:28:51 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Oct 2007 15:28:52 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Oct 2007 15:28:50 +0300 Received: from [172.21.35.48] (esdhcp03548.research.nokia.com [172.21.35.48]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9PCSmGH021395; Thu, 25 Oct 2007 15:28:49 +0300 In-Reply-To: <75FEE0DB-D9D7-4738-A68A-E816D08B03C7@nokia.com> References: <75FEE0DB-D9D7-4738-A68A-E816D08B03C7@nokia.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: Lars Eggert Subject: Re: [PCN] charter update Date: Thu, 25 Oct 2007 15:28:45 +0300 To: ext Lars Eggert X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 25 Oct 2007 12:28:50.0137 (UTC) FILETIME=[98D29490:01C81702] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0121120368==" Errors-To: pcn-bounces@ietf.org --===============0121120368== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-5-259760519; protocol="application/pkcs7-signature" --Apple-Mail-5-259760519 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Disregard this. This seems to have been stuck in a queue for 9 months :-) On 2007-1-23, at 17:15, ext Lars Eggert wrote: > Hi, > > as mentioned previously, I have edited the charter proposal posted > to this list in December to reflect the discussions that have > occurred on- and off-list. The main changes are a removal of the > SIP, application-based and pseudowire deployment scenarios, a > restructuring of the initial deliverables and milestones, and a set > of stronger retrictions. > > Please send comments! > > Lars > > > Description of Working Group: > > The Flow Admission and Preemption (FLAP) working group develops > flow admission and flow preemption mechanisms for deployment along > the edge of a network domain that protect the quality-of-service > that previously-admitted flows experience within the domain during > times of congestion. These mechanisms act on aggregated congestion > and pre-congestion signals from routers within the network domain > and control the admission of new flows into the domain or preempt > previously-admitted flows. Although designed to work together, flow > admission and flow preemption are independent mechanisms, and the > use of one does not require the use of the other. > > The FLAP WG will specify the following components of an integrated > flow admission and preemption mechanism: > > (1) a general architecture for flow admission and preemption based > on aggregated (pre-)congestion signals > > (2) conditions under which interior routers generate > (pre-)congestion signals > > (3) encoding and transport of (pre-)congestion signals > to the appropriate ingress routers of the network domain > > (4) edge router control mechanisms for flow admission and > preemption based on aggregated (pre-)congestion information > > The WG focuses on the overall architecture and specifically the > signaling interfaces needed to realize it. Standards-track > protocols are only developed when necessary for interoperability. > When algorithms are not necessary for interoperability the WG may > document examples or provide recommended solutions, however such > work should not be done at the expense of normative specifications. > > > The initial scope of the FLAP WG is restricted in the following ways: > > (A) develop these components for a single DiffServ region, > where all edge and interior routers are FLAP-enabled > and mutually trust each other > > (B) all flows handled by these mechanisms are inelastic and > constrained to a known maximum rate through policing or shaping > > (C) the number of flows across any potential aggregation bottleneck > is sufficiently large for stateless, statistical mechanisms > to be > effective > > (D) aggregation occurs either on links or ingress/egress pairs; > mechanisms must further define relevant limits > > (E) flows may have different precedence, but the applicability > of these mechanisms for emergency use (911, GETS, WPS, MLPP, > etc.) > is out of scope > > After completion of the initial phase, the FLAP WG may recharter to > develop solutions for scenarios where some of these restrictions > are not in place. It may also recharter to consider applying the > FLAP mechanisms to additional deployment scenarios (operation over > concatenated DiffServ regions, FLAP-aware application mechanisms, > etc.). The WG may also consider to investigate additional response > mechanisms that act on (pre-)congestion signals. One example could > be flow-rate adaptation (rather than flow admission/preemption) > during times of congestion. The details of these work items are > outside the scope of the initial phase; but the WG may want to > > However in the initial scope this mechanism is out-of-scope with > the exception that the developed solution should not, if possible, > prevent a future evolution to support this. > > > Goals and Milestones: > > Jul 2007 Flow Admission and Preemption Architecture > (Informational) > > Jul 2007 Survey of Encoding and Transport Choices of > (Pre-)Congestion Signals within a DiffServ Region > (Informational) > > Nov 2007 Flow Admission and Preemption within a DiffServ > Region (Informational) > > Nov 2007 (Pre-)Congestion Detection within a DiffServ Region > (Proposed Standard) > > Mar 2008 Encoding and Transport of (Pre-)Congestion Signals > within a DiffServ Region to Flow Egress (Proposed Standard) > > Mar 2008 Transport from Flow Egress in a DiffServ Region of > information > (possibly aggregated) or Admission/Preemption Signals to > DiffServ edge devices. (Proposed Standard) > > Mar 2008 Suggested Flow Admission and Preemption Edge Mechanisms > (Informational) > > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn --Apple-Mail-5-259760519 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzEwMjUxMjI4NDVaMCMGCSqGSIb3DQEJBDEWBBTgcB62Tf4xucxO BuH1sXETa5+37jCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAHoASdxgN/ChddgMQ39VqK2Ky4IuMKZ0wKhhJYIKNMJw3f7IMoR3L Gdae4FJFHZjnSrsQfdy1NqGOD4GNIYqTTlsRcbMzkxT1CNxF+IySBIKupRFIVa6nMs1IMxQg+zQK atLLuqsHJpt4vsoEqUr9nplIjhzaU0/b3Sd6prGt53kWCaObUYd8nqLJK1thUAE2TKxy9GGVoV7k bgRJuutk2gpf9l4QFg5MwRUJmWY/aFi5NAojqQqpEXvRBo/blo5TY2ws0vnA55wrSb51dFxdI2GN zpS4aY/NvAcDCM//RTYdh2yjAOTfMCmRwQSa5iLosaW8G/oAVFmuu5OtSlmgZAAAAAAAAA== --Apple-Mail-5-259760519-- --===============0121120368== 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 --===============0121120368==-- From pcn-bounces@ietf.org Thu Oct 25 08:32:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il1sl-0003Hk-No; Thu, 25 Oct 2007 08:32:15 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Il1sk-0003HU-4d for pcn-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 08:32:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il1sj-0003HM-Ph for pcn@ietf.org; Thu, 25 Oct 2007 08:32:13 -0400 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Il1sd-0001xP-Er for pcn@ietf.org; Thu, 25 Oct 2007 08:32:13 -0400 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.63]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Oct 2007 13:32: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] charter update Date: Thu, 25 Oct 2007 13:32:02 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC602@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC600@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] charter update Thread-Index: AcgW/6G6sBHpHUkESlKnZPBWkdDHQgAAN9ZwAACZOyA= From: To: , X-OriginalArrivalTime: 25 Oct 2007 12:32:02.0667 (UTC) FILETIME=[0B9453B0:01C81703] X-Spam-Score: -1.0 (-) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Sorry, please ignore below. Lars's email took 9 months to get delivered to me!! Phil/ -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: 25 October 2007 13:16 To: lars.eggert@nokia.com; pcn@ietf.org Subject: RE: [PCN] charter update A quick first one - any chance of sticking with 'termination'? I just got used to it rather than pre-emption! [I know FLAP is more amusing than FLAT...] phil -----Original Message----- From: Lars Eggert [mailto:lars.eggert@nokia.com]=20 Sent: 23 January 2007 15:15 To: pcn@ietf.org Subject: [PCN] charter update Hi, as mentioned previously, I have edited the charter proposal posted to =20 this list in December to reflect the discussions that have occurred =20 on- and off-list. The main changes are a removal of the SIP, =20 application-based and pseudowire deployment scenarios, a =20 restructuring of the initial deliverables and milestones, and a set =20 of stronger retrictions. Please send comments! Lars Description of Working Group: The Flow Admission and Preemption (FLAP) working group develops flow =20 admission and flow preemption mechanisms for deployment along the =20 edge of a network domain that protect the quality-of-service that =20 previously-admitted flows experience within the domain during times =20 of congestion. These mechanisms act on aggregated congestion and pre-=20 congestion signals from routers within the network domain and control =20 the admission of new flows into the domain or preempt previously-=20 admitted flows. Although designed to work together, flow admission =20 and flow preemption are independent mechanisms, and the use of one =20 does not require the use of the other. The FLAP WG will specify the following components of an integrated =20 flow admission and preemption mechanism: (1) a general architecture for flow admission and preemption based on aggregated (pre-)congestion signals (2) conditions under which interior routers generate (pre-)congestion signals (3) encoding and transport of (pre-)congestion signals to the appropriate ingress routers of the network domain (4) edge router control mechanisms for flow admission and preemption based on aggregated (pre-)congestion information The WG focuses on the overall architecture and specifically the =20 signaling interfaces needed to realize it. Standards-track protocols =20 are only developed when necessary for interoperability. When =20 algorithms are not necessary for interoperability the WG may document =20 examples or provide recommended solutions, however such work should =20 not be done at the expense of normative specifications. The initial scope of the FLAP WG is restricted in the following ways: (A) develop these components for a single DiffServ region, where all edge and interior routers are FLAP-enabled and mutually trust each other (B) all flows handled by these mechanisms are inelastic and constrained to a known maximum rate through policing or shaping (C) the number of flows across any potential aggregation bottleneck is sufficiently large for stateless, statistical mechanisms =20 to be effective (D) aggregation occurs either on links or ingress/egress pairs; mechanisms must further define relevant limits (E) flows may have different precedence, but the applicability of these mechanisms for emergency use (911, GETS, WPS, MLPP, =20 etc.) is out of scope After completion of the initial phase, the FLAP WG may recharter to =20 develop solutions for scenarios where some of these restrictions are =20 not in place. It may also recharter to consider applying the FLAP =20 mechanisms to additional deployment scenarios (operation over =20 concatenated DiffServ regions, FLAP-aware application mechanisms, =20 etc.). The WG may also consider to investigate additional response =20 mechanisms that act on (pre-)congestion signals. One example could be =20 flow-rate adaptation (rather than flow admission/preemption) during =20 times of congestion. The details of these work items are outside the =20 scope of the initial phase; but the WG may want to However in the initial scope this mechanism is out-of-scope with the =20 exception that the developed solution should not, if possible, =20 prevent a future evolution to support this. Goals and Milestones: Jul 2007 Flow Admission and Preemption Architecture (Informational) Jul 2007 Survey of Encoding and Transport Choices of (Pre-)Congestion Signals within a DiffServ Region (Informational) Nov 2007 Flow Admission and Preemption within a DiffServ Region (Informational) Nov 2007 (Pre-)Congestion Detection within a DiffServ Region (Proposed Standard) Mar 2008 Encoding and Transport of (Pre-)Congestion Signals within a DiffServ Region to Flow Egress (Proposed Standard) Mar 2008 Transport from Flow Egress in a DiffServ Region of =20 information (possibly aggregated) or Admission/Preemption Signals to DiffServ edge devices. (Proposed Standard) Mar 2008 Suggested Flow Admission and Preemption Edge Mechanisms (Informational) _______________________________________________ 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 Oct 25 09:53:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il39e-0004RB-PX; Thu, 25 Oct 2007 09:53:46 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Il39c-0004R1-VN for pcn-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 09:53:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il39c-0004Qt-LQ for pcn@ietf.org; Thu, 25 Oct 2007 09:53:44 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Il39W-0004Am-8N for pcn@ietf.org; Thu, 25 Oct 2007 09:53:44 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-5.cisco.com with ESMTP; 25 Oct 2007 06:53:22 -0700 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9PDrL1i012747; Thu, 25 Oct 2007 09:53:21 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l9PDrHPo028497; Thu, 25 Oct 2007 13:53:21 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Oct 2007 09:53:08 -0400 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] RSVP and ECMP Date: Thu, 25 Oct 2007 09:53:00 -0400 Message-ID: In-Reply-To: <47206C56.80809@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] RSVP and ECMP Thread-Index: AcgW7/yp+KPMF8fDQ3SReDxR5RWDcQAHcoXg From: "Anna Charny (acharny)" To: "Hannes Tschofenig" , "Georgios Karagiannis" X-OriginalArrivalTime: 25 Oct 2007 13:53:08.0383 (UTC) FILETIME=[5FC5AAF0:01C8170E] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15504.002 X-TM-AS-Result: No--37.291800-8.000000-2 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5161; t=1193320401; x=1194184401; 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]=20RSVP=20and=20ECMP |Sender:=20 |To:=20=22Hannes=20Tschofenig=22=20, =0A=20=20= 20=20=20=20=20=20=22Georgios=20Karagiannis=22=20; bh=o3CaNvysyGZ3idsn7FG9+UlLL9jwjhrWYscVD7TNOBk=; b=aNEgknW//iAOtGM+emB/vJOjM409WBF16fwyFtMpJfxUeJdens6VEDy4d9I+myDUvOPN6zrV OSwHcR68AaV9yC2TNBfgituBqMiC0m1OGbg8EliM+rzubn3IrByUxGWj; Authentication-Results: rtp-dkim-1; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Hannes, >=20 > The problems obviously show up if the load balancing device=20 > does not inspect the RSVP traffic. > Then, you cannot ensure that the signaling traffic follows=20 > the data traffic anymore. >=20 Sorry, I did not quite understand your point. Wouldn't a packet carrying RSVP message be processes just like any other packet in the node which is not RSVP-capable? So all that matters for the discussion on using RSVP message as a probe is whether that packet goes the same way as the corresponding data packets of the same flow under ecpm decisions? Am I missing the point you are making? Anna > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Thursday, October 25, 2007 6:14 AM > To: Georgios Karagiannis > Cc: pcn@ietf.org > Subject: Re: [PCN] RSVP and ECMP >=20 > The problems obviously show up if the load balancing device=20 > does not inspect the RSVP traffic. > Then, you cannot ensure that the signaling traffic follows=20 > the data traffic anymore. >=20 > Also with tunnels you need to ensure that at least one of the=20 > tunnel endpoints is aware of the signaling protocol. This=20 > might seem to be a simple requirement but I assume in reality=20 > it is not that easy. This is the area where complexity says=20 > HELLO to path-coupled signaling. >=20 > Ciao > Hannes >=20 > PS: When you still think that it is totally trivial then you=20 > might want to look at the many tunneling schemes folks use or=20 > want to use. >=20 > Georgios Karagiannis wrote: > > Hi Bruce, Hi all > > > > I agree with Bruce! If it is to use probing, then we have to ensure=20 > > that the probes should get the similar correct ECMP=20 > treatment as the=20 > > correct ECMP treatment achieved by RSVP. > > > > This means that the probe messages have to have the same=20 > addresses and=20 > > ports as the data. > > I think tat this is not difficult and not complex to be achieved. > > > > Best regards, > > Georgios > > > > > > > > On 10/23/2007, "Bruce Davie" wrote: > > > > =20 > >> Michael, > >> RSVP tries to forward the Path exactly the same way that it would=20 > >> forward the data. Since Path messages are processed outside of the=20 > >> fast path, it is possible for the router to look at=20 > anything that is=20 > >> in the path message, including source addr, dest addr, and port=20 > >> numbers, and figure out where a data packet that had those=20 > values in=20 > >> its IP header would get forwarded. It sends the Path=20 > message out that=20 > >> interface. In practice, this takes care of the vast=20 > majority of ECMP=20 > >> algorithms. This approach is implemented today. > >> > >> If ECMP was using something from the IP or higher layer=20 > header that=20 > >> was not in the Path message, then a problem would arise. > >> > >> So, practically speaking, if the probe messages have the same=20 > >> addresses and ports as the data, they should get correct ECMP=20 > >> treatment. Or at least, fare no worse than RSVP. > >> > >> Bruce > >> > >> On Oct 23, 2007, at 12:07 PM, Michael Menth wrote: > >> > >> =20 > >>> Hi, > >>> > >>> I've got a question regarding RSVP. PATH messages need to=20 > be carried=20 > >>> over the same path as subsequent data packets. How is=20 > this achieved=20 > >>> in the presence of ECMP routing? In theory, PATH messages=20 > can take a=20 > >>> different route than data packets if the load balancer takes=20 > >>> arbitrary parts of the header(s) to calculate a suitable=20 > hash value,=20 > >>> which decides which route the packet will take. > >>> > >>> This issue seems to be related to the problem of how to make sure=20 > >>> that PCN probe messages take the same path as subsequent PCN data=20 > >>> packets, provided that they have the same source and destination=20 > >>> ports and addresses. > >>> > >>> I am interested in how this problem is solved in practice=20 > or whether=20 > >>> it is intentionally avoided. > >>> > >>> Regards, > >>> > >>> Michael > >>> > >>> -- > >>> Dr. Michael Menth, Assistant Professor University of Wuerzburg,=20 > >>> Institute of Computer Science Am Hubland, D-97074 Wuerzburg,=20 > >>> Germany, room B206 > >>> phone: (+49)-931/888-6644, fax: (+49)-931/888-6632=20 > >>> 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 > >>> =20 > >> _______________________________________________ > >> PCN mailing list > >> PCN@ietf.org > >> https://www1.ietf.org/mailman/listinfo/pcn > >> =20 > > > > > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www1.ietf.org/mailman/listinfo/pcn > > =20 >=20 >=20 >=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn >=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Oct 25 10:00:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il3GE-0004sU-1r; Thu, 25 Oct 2007 10:00:34 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Il3GC-0004s9-Fy for pcn-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 10:00:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il3GC-0004s1-66 for pcn@ietf.org; Thu, 25 Oct 2007 10:00:32 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Il3G4-0004Rl-C8 for pcn@ietf.org; Thu, 25 Oct 2007 10:00:32 -0400 Received: (qmail invoked by alias); 25 Oct 2007 14:00:15 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp021) with SMTP; 25 Oct 2007 16:00:15 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/WZu5OWs/WOp4EuUGtn1c+9mXSo5o3T9PHSuQIom ZK9xHzbUoYPx6k Message-ID: <4720A16F.6050409@gmx.net> Date: Thu, 25 Oct 2007 16:00:15 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Anna Charny (acharny)" Subject: Re: [PCN] RSVP and ECMP References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Anna, Anna Charny (acharny) wrote: > Hi Hannes, > > >> The problems obviously show up if the load balancing device >> does not inspect the RSVP traffic. >> Then, you cannot ensure that the signaling traffic follows >> the data traffic anymore. >> >> > > Sorry, I did not quite understand your point. Wouldn't a packet > carrying RSVP message be processes just like any other packet in the > node which is not RSVP-capable? Theoretically yes. It just depends on the behavior of the box. The RSVP packet is, however, not a data packet. It looks different. > So all that matters for the discussion > on using RSVP message as a probe is whether that packet goes the same > way as the corresponding data packets of the same flow under ecpm > decisions? Correct, and the question is: Is it possible that data traffic travels along a different path than the signaling traffic. The answer is "yes" (unless you have control over the box making the decisions). > Am I missing the point you are making? > > Ciao Hannes > Anna > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Thursday, October 25, 2007 6:14 AM >> To: Georgios Karagiannis >> Cc: pcn@ietf.org >> Subject: Re: [PCN] RSVP and ECMP >> >> The problems obviously show up if the load balancing device >> does not inspect the RSVP traffic. >> Then, you cannot ensure that the signaling traffic follows >> the data traffic anymore. >> >> Also with tunnels you need to ensure that at least one of the >> tunnel endpoints is aware of the signaling protocol. This >> might seem to be a simple requirement but I assume in reality >> it is not that easy. This is the area where complexity says >> HELLO to path-coupled signaling. >> >> Ciao >> Hannes >> >> PS: When you still think that it is totally trivial then you >> might want to look at the many tunneling schemes folks use or >> want to use. >> >> Georgios Karagiannis wrote: >> >>> Hi Bruce, Hi all >>> >>> I agree with Bruce! If it is to use probing, then we have to ensure >>> that the probes should get the similar correct ECMP >>> >> treatment as the >> >>> correct ECMP treatment achieved by RSVP. >>> >>> This means that the probe messages have to have the same >>> >> addresses and >> >>> ports as the data. >>> I think tat this is not difficult and not complex to be achieved. >>> >>> Best regards, >>> Georgios >>> >>> >>> >>> On 10/23/2007, "Bruce Davie" wrote: >>> >>> >>> >>>> Michael, >>>> RSVP tries to forward the Path exactly the same way that it would >>>> forward the data. Since Path messages are processed outside of the >>>> fast path, it is possible for the router to look at >>>> >> anything that is >> >>>> in the path message, including source addr, dest addr, and port >>>> numbers, and figure out where a data packet that had those >>>> >> values in >> >>>> its IP header would get forwarded. It sends the Path >>>> >> message out that >> >>>> interface. In practice, this takes care of the vast >>>> >> majority of ECMP >> >>>> algorithms. This approach is implemented today. >>>> >>>> If ECMP was using something from the IP or higher layer >>>> >> header that >> >>>> was not in the Path message, then a problem would arise. >>>> >>>> So, practically speaking, if the probe messages have the same >>>> addresses and ports as the data, they should get correct ECMP >>>> treatment. Or at least, fare no worse than RSVP. >>>> >>>> Bruce >>>> >>>> On Oct 23, 2007, at 12:07 PM, Michael Menth wrote: >>>> >>>> >>>> >>>>> Hi, >>>>> >>>>> I've got a question regarding RSVP. PATH messages need to >>>>> >> be carried >> >>>>> over the same path as subsequent data packets. How is >>>>> >> this achieved >> >>>>> in the presence of ECMP routing? In theory, PATH messages >>>>> >> can take a >> >>>>> different route than data packets if the load balancer takes >>>>> arbitrary parts of the header(s) to calculate a suitable >>>>> >> hash value, >> >>>>> which decides which route the packet will take. >>>>> >>>>> This issue seems to be related to the problem of how to make sure >>>>> that PCN probe messages take the same path as subsequent PCN data >>>>> packets, provided that they have the same source and destination >>>>> ports and addresses. >>>>> >>>>> I am interested in how this problem is solved in practice >>>>> >> or whether >> >>>>> it is intentionally avoided. >>>>> >>>>> 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 >>>> >>>> >>> _______________________________________________ >>> 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 Oct 26 05:11:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlLEK-0006eM-DJ; Fri, 26 Oct 2007 05:11:48 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IlLEK-0006eF-57 for pcn-confirm+ok@megatron.ietf.org; Fri, 26 Oct 2007 05:11:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlLEJ-0006dF-RO for pcn@ietf.org; Fri, 26 Oct 2007 05:11:47 -0400 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlLEA-0004E0-G9 for pcn@ietf.org; Fri, 26 Oct 2007 05:11:45 -0400 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.63]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Oct 2007 10:11:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] LC-PCN version 01 uploaded Date: Fri, 26 Oct 2007 10:11:19 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC606@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] LC-PCN version 01 uploaded Thread-Index: AcgW5hh6dnktQznrQdCxy1g9MGORMgAxt99g From: To: , , X-OriginalArrivalTime: 26 Oct 2007 09:11:20.0620 (UTC) FILETIME=[2C5F86C0:01C817B0] X-Spam-Score: -1.0 (-) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org In-line Thanks Phil > > > Let me summarise to make sure I understand it right. > > > > - two encodings are used. one ('PCN-marking') is used for > > both adm ctrl & termination to indicate the excess traffic. > > If a PCN-interior-node is PCN-marking some pkts, then it > > marks all other pkts with another encoding ('affected marking') >=20 > Georgios: Yes, you are right. All other packets are marked > using the "PCN_Affected_marking" encoding. >=20 > > > > - the 'PCN-marking' algorithm has several regimes: > > * when traffic rate is below PCN-lower-rate, no pkts are marked > > * as the traffic rate climbs above the PCN-lower-rate, an > > increasing number of pkts are marked (marking rate =3D excess > > rate divided by N) [adm ctrl state] >=20 > Georgios: It is more complicated than that! Please check the > pseudocode on page 13. The packets are PCN-marking encoded > only if the incoming_PCN_marking_rate is smaller or equal to > the Admission_offset_rate. Where the incoming_PCN_marking_rate > is actualy the rate of incoming packets that are PCN_marked. >=20 > > * at some rate (PCN-lower-rate + adm-offset-rate), then pkts > > are marked at the same rate, even if the traffic rate climbs > > higher [adm ctrl state] >=20 > Georgios: No, if the incoming_PCN_marking_rate is higher than the > Admission_offset_rate than no anymore packets are PCN_marked. > They are however marked as PCN_Affected_marking! >=20 > > * when the traffic rate reaches the PCN-upper-rate, > > additional pkts are marked (additional marking rate =3D excess > > rate above PCN-upper-rate divided by N) [termination ctrl state] >=20 > Georgios: It is again more complicated than that, please > see the pseudocode on Page 20. Similar to the admission control state > the rate of packets to be marked also depends on > the incoming_PCN_marking_rate. Moreover, if the interior node is > in termination ctrl state > then the additional marking rate is using the sliding window > algorithm to overcome the undershooting issue, see page 19 and page 20. >=20 >=20 > > * if pkts arrive already PCN-marked, then the node measures > > the rate of pkts already marked & works out what excess rate > > this corresponds to, and only marks additional pkts if its > > own excess rate is even higher. >=20 > Georgios: Well, it is more complicated than that. Please see pseudo > code onn page 13 and page 20, the > rate of the already PCN_marked packets is denoted in the pseudocode > as incoming_PCN_marking_rate. >=20 >=20 > > * the PCN-egress-node measures the rate of PCN-marked pkts > > and determines whether the overloaded node is in adm ctrl > > state or termination ctrl state >=20 > Georgios: Yes, but it is more complicated than that please see > pseudo code on page 14 and on page 23. >=20 [phil] I'm now confused whether I understand your algo. I should have said: my first bullets were all assuming that no pkts arrived already PCN-marked, ie incoming_PCN_marking_rate =3D 0. Is my summary correct with this assumption? Also, the pcn-egres-node determining what state it's in. I was reading the description on page 21-22. pges 14 & 23 don't seem to have relevant pseudocode? > > > > Questions: > > - I don't understand the point of doing PCN-marking in the adm ctrl > > state. When it comes to making an adm decision, you send a (single) > > probe pkt - if it's PCN-marked or affected-marked then you block the > > call. So when a node's in the adm ctrl state, it could just do > > affected-marking of all pkts. Wouldn't that work just as well? >=20 > Georgios: this algorithm can provide admission control even if > probing is not used. However, by using probing we ensure that the > flow that is requesting access is passing through the interior node > that is either in admission control state or flow termination state. [phil] ok. >=20 > > - with you current algo, imagine there are two paths through the nw: > > A-B-X-D > > A-M-N-X-D > > If B & N are both in adm ctrl state then they both will do > > PCN-marking. > > At the PCN-egress-node the PCN-marking rate may be high enough that it > > believes termination is needed. Are there topologies/scenarios where > > this could happen? I think your multicongestion_error > > parameter in S3.4 > > is connected to this problem; I didn't find your discussion about it > > convincing >=20 > Georgios: You are right, the multicongestion_error parameter in S3.4 > is used to emphasize the multicongestion error bounds in this > calculation. Note that > the calculation of this error bound can only be estimated by off line > tests in a predefined network scenario. > Note that by using the dependency of the incoming_PCN_marking_rate > the multicongestion error bound can be decreased. [phil] ok. I don't like this. the idea of PCN is to be a measurement-based approach so don't have to do these kind of off-line tests. In particular, there'll be wrong when the network is suffering from failures - the strength of a measurement-based approach should exactly be that it gracefully adapts despite network failures.=20 >=20 > > - the 'affected marking' is claimed to solve ECMP issues. However, the > > same affected marking is used in both adm ctrl state & > > termination ctrl > > state - I don't think this works. Imagine that a node [node-1] on one > > path is in adm ctrl state & a node [node-2] on another path is in > > termination ctrl state. Therefore flows are terminated, and only flows > > that are being PCN-marked or affected-marked are terminated. However > > this could lead to flows being terminated that go through > > node-1; node-2 > > will still be just as badly overloaded. >=20 > Georgios: In admission control state, probing is used to ensure that > the packets associated to a requesting flow are passing through the > congested PCN_interior node. ECMP is one > of the issues that are associated with the fact that packets of a flow can > follow a different path than the path followed by an aggregate of flows > (starting from the same ingress and ending at the same egress). > In order to accomplish this the probe packets should be marked using > either PCN_marking encoding or the PCN_Affected_marking encoding. > In flow termination state, both the PCN_marking and PCN_Affected_marking > encoded packets are used to ensure that the flows that are selected for > termination are indeed passing through a severely congested node. > Note that the issue that you described above is associated to the > multicongestion-error bounds. Therefore, this multicongestion-error bound > should be estimated as much as > accurate as possible. [phil] ok, so you agree this is a problem.=20 >=20 > > - in the termination algorithm, S4.2.2, the "termination_offset_rate" > > factor makes no sense to me >=20 > Georgios: Why not? [phil] well I don't understand what the point of it is. I thought I understood the point of the *admission* offset_rate and I couldn't see why anything similar was needed for termination. But maybe I misunderstood the adm-offset-rate as well! >=20 > > - the parameters PCN_lower_rate_egress & PCN_upper_rate_egress are > > expressed in the wrong units (you have conditions like > > signalled_overload_rate > PCN_lower_rate_egress; the former is a rate, > > the latter a % so some tweaking is needed to convert the latter into a > > rate) >=20 > Georgios: You are right, a conversion is needed to convert the latter > into a rate. [phil] ok. So everything is rate. Note this raises Anna's qu: * if pcn_lower_rate_eggress (and pcn_uppre-rate_egress) are absolute rates, then how do you choose that abslolute rate value, given that the rates of ingress-egress aggregates at the same ingress may be vastly different in magnitude? >=20 >=20 > > > > best wishes > > > > phil/ > > > > > -----Original Message----- > > > From: Anurag Bhargava (RL/TNT) [mailto:anurag.bhargava@ericsson.com] > > > Sent: 11 September 2007 12:36 > > > To: pcn > > > Subject: [PCN] LC-PCN version 01 uploaded > > > > > > Hello, > > > FYI - We have uploaded a new version of the PCN draft. The major > > > changes are some clarification and adopting to the > > Architecture draft > > > terminology. > > > > > > "LC-PCN: The Load Control PCN Solution", Lars Westberg, 5-Sep-07, > > > > > > > > > Please let me know if you have any questions. > > > > > > Thanks, > > > -Anurag Bhargava, Ph.D. > > > > > > > > > _______________________________________________ > > > PCN mailing list > > > PCN@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pcn > > > > > > _______________________________________________ > > 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 Oct 26 09:43:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlPTK-00089U-IH; Fri, 26 Oct 2007 09:43:34 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IlPTK-00089P-2C for pcn-confirm+ok@megatron.ietf.org; Fri, 26 Oct 2007 09:43:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlPTJ-00088j-Ox for pcn@ietf.org; Fri, 26 Oct 2007 09:43:33 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlPTB-0004jl-HN for pcn@ietf.org; Fri, 26 Oct 2007 09:43:31 -0400 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l9QDgqwB007699 for ; Fri, 26 Oct 2007 08:43:08 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Oct 2007 08:43:04 -0500 Received: from [147.117.169.183] ([147.117.169.183]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Oct 2007 08:43:02 -0500 From: Steven Blake To: pcn Content-Type: multipart/mixed; boundary="=-+bB7akY3hEY+nXUYajIv" Organization: Ericsson IP Infrastructure Date: Fri, 26 Oct 2007 09:43:02 -0400 Message-Id: <1193406182.3841.36.camel@neutrino> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) X-OriginalArrivalTime: 26 Oct 2007 13:43:03.0028 (UTC) FILETIME=[215D9340:01C817D6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Subject: [PCN] [Fwd: Internet-Drafts Submission Cutoff Dates for the 70th IETF Meeting in Vancouver, BC, Canada] X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org --=-+bB7akY3hEY+nXUYajIv Content-Type: text/plain Content-Transfer-Encoding: 7bit FYI =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven Blake Ericsson/Redback Networks +1 919-472-9913 --=-+bB7akY3hEY+nXUYajIv Content-Disposition: inline Content-Description: Forwarded message - Internet-Drafts Submission Cutoff Dates for the 70th IETF Meeting in Vancouver, BC, Canada Content-Type: message/rfc822 Return-path: Envelope-to: slblake@petri-meat.com Delivery-date: Fri, 26 Oct 2007 00:21:16 -0400 Received: from megatron.ietf.org ([156.154.16.145]) by elom.tchmachines.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1IlGh9-0006tz-LX for slblake@petri-meat.com; Fri, 26 Oct 2007 00:21:15 -0400 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlGMp-00010I-Au; Fri, 26 Oct 2007 00:00:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlGMn-000109-AW for ietf-announce@ietf.org; Fri, 26 Oct 2007 00:00:13 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlGMm-0000mP-VN for ietf-announce@ietf.org; Fri, 26 Oct 2007 00:00:13 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id AAEEE17617 for ; Fri, 26 Oct 2007 04:00:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IlGMc-0001Vw-76 for ietf-announce@ietf.org; Fri, 26 Oct 2007 00:00:02 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: ietf-announce@ietf.org Cc: From: ietf-secretariat@ietf.org Message-Id: Date: Fri, 26 Oct 2007 00:00:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: Internet-Drafts Submission Cutoff Dates for the 70th IETF Meeting in Vancouver, BC, Canada X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-announce-bounces@ietf.org Content-Transfer-Encoding: 7bit There are two (2) Internet-Draft cutoff dates for the 70th IETF Meeting in Vancouver, BC, Canada: November 12th: Cutoff Date for Initial (i.e., version -00) Internet-Draft Submissions All initial Internet-Drafts (version -00) must be submitted by Monday, November 12th at 9:00 AM ET (14:00 UTC/GMT). As always, all initial submissions with a filename beginning with "draft-ietf" must be approved by the appropriate WG Chair before they can be processed or announced. The Secretariat would appreciate receiving WG Chair approval by Monday, November 5th at 9:00 AM ET (14:00 UTC/GMT). November (14:00 UTC/GMT): Cutoff Date for Revised (i.e., version -01 and higher) Internet-Draft Submissions All revised Internet-Drafts (version -01 and higher) must be submitted by Monday, November 19th at 9:00 AM ET (14:00 UTC/GMT). Initial and revised Internet-Drafts received after their respective cutoff dates will not be made available in the Internet-Drafts directory or announced until on or after Monday, December 3rd at 9:00 AM ET (14:00 UTC/GMT), when Internet-Draft posting resumes. Please do not wait until the last minute to submit. The Secretariat encourages you to submit your Internet-Drafts via the Internet-Draft Submission Tool (IDST) https://datatracker.ietf.org/idst/upload.cgi. If you are unable to do so, then you may still submit your Internet- Drafts manually by sending them to internet-drafts@ietf.org. If you are submitting a version -00 WG draft that replaces non-WG draft, then you must submit it manually as the current IDST cannot handle replacements. Please be sure to state that one draft replaces another in the cover note that accompanies your submission. Also, please note that the IDST will not accept drafts submitted after their respective cutoff dates. Thank you for your understanding and cooperation. If you have any questions or concerns, then please send a message to internet-drafts@ietf.org. The IETF Secretariat FYI: The Internet-Draft cutoff dates as well as other significant dates for the 70th IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_70.html. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce --=-+bB7akY3hEY+nXUYajIv 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 --=-+bB7akY3hEY+nXUYajIv-- From pcn-bounces@ietf.org Mon Oct 29 15:15:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ima5J-0002hh-0X; Mon, 29 Oct 2007 15:15:37 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Ima5F-0002dm-9w for pcn-confirm+ok@megatron.ietf.org; Mon, 29 Oct 2007 15:15:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ima5E-0002da-VA; Mon, 29 Oct 2007 15:15:33 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ima5E-0007oH-GG; Mon, 29 Oct 2007 15:15:32 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 20C81175D0; Mon, 29 Oct 2007 19:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Ima4j-00062z-LA; Mon, 29 Oct 2007 15:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 29 Oct 2007 15:15:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: pcn@ietf.org Subject: [PCN] I-D ACTION:draft-ietf-pcn-architecture-01.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Congestion and Pre-Congestion Notification Working Group of the IETF. Title : Pre-Congestion Notification Architecture Author(s) : P. Eardley Filename : draft-ietf-pcn-architecture-01.txt Pages : 36 Date : 2007-10-29 The purpose of this document is to describe a general architecture for flow admission and termination based on aggregated pre-congestion information in order to protect the quality of service of established inelastic flows within a single DiffServ domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-architecture-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pcn-architecture-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pcn-architecture-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-10-29141806.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pcn-architecture-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pcn-architecture-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-10-29141806.I-D@ietf.org> --OtherAccess-- --NextPart 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 --NextPart-- From pcn-bounces@ietf.org Mon Oct 29 15:58:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImakM-0002pR-To; Mon, 29 Oct 2007 15:58:02 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1ImakK-0002pE-TT for pcn-confirm+ok@megatron.ietf.org; Mon, 29 Oct 2007 15:58:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImakK-0002St-H8 for pcn@ietf.org; Mon, 29 Oct 2007 15:58:00 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Imak9-0002aU-RE for pcn@ietf.org; Mon, 29 Oct 2007 15:57:50 -0400 Received: from mailhub.lss.emc.com (uraeus.lss.emc.com [10.254.144.14]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l9TJvkTC004561; Mon, 29 Oct 2007 15:57:46 -0400 (EDT) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l9TJvYRE021794; Mon, 29 Oct 2007 15:57:43 -0400 (EDT) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Oct 2007 15:57:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PCN] PCN & tunnelling Date: Mon, 29 Oct 2007 15:57:38 -0400 Message-ID: In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC5F7@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN & tunnelling Thread-Index: AcgWJ+54M2I8eYc4QJu/kWUfuySz/QAGbMXgAAt1T+AA8fzNIA== References: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC5F7@E03MVZ1-UKDY.domain1.systemhost.net> To: , X-OriginalArrivalTime: 29 Oct 2007 19:57:39.0356 (UTC) FILETIME=[F58A4DC0:01C81A65] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.51425 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, HTML_50_70 0.1, HTML_NO_HTTP 0.1, SUPERLONG_LINE 0.05, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __HAS_MSGID 0, __HTML_BOLD 0, __HTML_FONT_BLUE 0, __IMS_MSGID 0, __MIME_HTML 0, __MIME_VERSION 0, __SANE_MSGID 0, __TAG_EXISTS_HTML 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 93ea548d5fde6eb89af31f1faab96344 Cc: X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0590612827==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0590612827== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C81A65.F4F8F42C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C81A65.F4F8F42C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Phil, =20 As the author of RFC 2983, I was going to point you to this text. =20 Regarding the characteristics of the other end of the tunnel, there isn't any magic; one has to know this (or figure it out) as part of setting up the tunnel. RFC 2983 was written from a core networks point of view so the expected sort of tunnel is one being used for traffic management, so its reasonable to expect that the nature of the other endpoint is known when the tunnel is set up. =20 If in doubt, clearing out everything (e.g., DSCP of 0) is generally a good course of action for a tunnel headed elsewhere, and if the tunnel winds up back in the same domain, unbeknownst to the admins, shame on those who weren't paying attention. =20 Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- ________________________________ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: Wednesday, October 24, 2007 3:06 PM To: acharny@cisco.com; pcn@ietf.org Subject: RE: [PCN] PCN & tunnelling =09 =09 Anna, =20 I don't know. =20 For inspiration, I looked at rfc2983, diffserv & tunnels. S3.2 of this talks about partially capable DS configs - only tunnel ingress is DS-capable but not the egress. It says that=20 If tunnel decapsulation processing discards the outer header's DSCP value without changing the inner header's DSCP value, the DS-capable tunnel ingress node is obligated to set the inner header's DSCP to a value compatible with the network at the tunnel egress. The value 0 [is a good suggestion] =20 this approach is along the same lines to the one in the original email below. Unfortunately 2983 doesn't say how the tunnel ingress node knows about the characteristics of the network at the tunnel egress. Did the DS people have anything in mind that might apply in the PCN case? =20 phil =20 -----Original Message----- From: Anna Charny (acharny) [mailto:acharny@cisco.com]=20 Sent: 24 October 2007 14:30 To: Eardley,PL,Philip,CXR9 R; pcn@ietf.org Subject: RE: [PCN] PCN & tunnelling =20 Hi Phil, =20 Question: what would be the mechanism for knowing whether the egress of the tunnel is in the PCN domain or not? Are we assuming that a node somehow advertises its PCN capability? I do not think we ever explicitly assumed that? =20 Anna=20 =20 =09 ________________________________ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: Wednesday, October 24, 2007 6:24 AM To: pcn@ietf.org Subject: [PCN] PCN & tunnelling Hi, =20 I was chatting with Bob about section 5.8 tunnelling. We've realised there's the following nasty case which we hadn't thought about. The scenario is when a tunnel starts inside a PCN-domain and finishes outside it.=20 =20 First we follow what happens when the current text is followed. Imagine that the pkt is PCN-marked by some PCN-node before the tunnel start node. On encapsulation the PCN-mark is copied onto the outer header. Hence the PCN-egress-node 'sees' the PCN-mark as normal - this is ok. The PCN-egress-node clears the marking in the (outer) header and forwards the pkt into the next domain. The pkt is decapsulated at the tunnel end point. But the decapsulated pkt is already PCN-marked. Potential problems: [1] if it's decapsulated in a non-PCN-domain, then the pkt may confuse nodes in this domain [depending on what encoding is used for a PCN-mark] ; [2] if it's decapsulated in a PCN-domain, then the pkt is PCN-marked [which might lead this PCN-domain to terminate or block a flow unnecessarily]. =20 The problem arises because the PCN-egress-node clears PCN-marking on the outer header but not on the inner header. (This is a new problem compared with ECN & tunnelling.)=20 =20 Possible solution: if the pkt is PCN-marked, then the tunnel start node checks whether the tunnel egress is inside or outside the PCN-domain - if it's outside, then it clears the PCN-marking on the inner header (effectively it does this on behalf of the PCN-egress-node). (Also, the PCN-mark is copied onto the outer header, as the current text says.) =20 Thoughts? =20 Thanks, Phil/ =20 ------_=_NextPart_001_01C81A65.F4F8F42C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Phil,
 
As the author of RFC 2983, I was going to = point you to=20 this text.
 
Regarding the characteristics of the other = end of the=20 tunnel, there
isn't any magic; one has to know this = (or figure it=20 out) as part of
setting up the tunnel.  RFC 2983 was = written from a=20 core networks
point of view so the = expected = sort of tunnel=20 is one being used for
traffic management, so its = reasonable to=20 expect that the nature = of
the other endpoint is known = when the = tunnel is set=20 up.
 
If in doubt, clearing out everything (e.g., = DSCP of 0)=20 is generally
a good course of action for a tunnel headed=20 elsewhere, and if the
tunnel winds up back in the same=20 domain, unbeknownst to the = admins,
shame on those who weren't paying = attention.
 
Thanks,
--David
----------------------------------------------------
David=20 L. Black, Distinguished Engineer
EMC Corporation, 176 South St., = Hopkinton,=20 MA  01748
+1 (508)=20 293-7953           = ; =20 FAX: +1 (508)=20 293-7786
black_david@emc.com       = =20 Mobile: +1 (978)=20 394-7754
----------------------------------------------------

From: philip.eardley@bt.com=20 [mailto:philip.eardley@bt.com]
Sent: Wednesday, October 24, = 2007=20 3:06 PM
To: acharny@cisco.com; = pcn@ietf.org
Subject: RE:=20 [PCN] PCN & tunnelling

Anna,

 

I = don’t=20 know.

 

For = inspiration, I=20 looked at rfc2983, diffserv & tunnels. S3.2 of this talks about = partially=20 capable DS configs – only tunnel ingress is DS-capable but not = the egress. It=20 says that 

If tunnel decapsulation =
processing discards
   the outer header's =
DSCP value without changing the inner =
header's
   DSCP value, the =
DS-capable tunnel ingress node is obligated to =
set
   the inner header's DSCP to a =
value compatible with the network at the
   tunnel egress.  The value 0 [is a good =
suggestion]

 

this = approach is=20 along the same lines to the one in the original email below. = Unfortunately=20 2983 doesn’t say how the tunnel ingress node knows about the = characteristics=20 of the network at the tunnel egress. Did the DS people have anything = in mind=20 that might apply in the PCN case?

 

phil

 

-----Original=20 Message-----
From: = Anna=20 Charny (acharny) [mailto:acharny@cisco.com]
Sent: 24 October 2007 = 14:30
To: Eardley,PL,Philip,CXR9 R;=20 pcn@ietf.org
Subject: RE:=20 [PCN] PCN & tunnelling

 

Hi=20 Phil,

 

Question: = what would=20 be the mechanism for knowing whether the egress of the tunnel is in = the PCN=20 domain or not?  Are we assuming that a node somehow advertises = its PCN=20 capability?  I do not think we ever explicitly assumed=20 that?

 

Anna=20

 

From: = philip.eardley@bt.com=20 [mailto:philip.eardley@bt.com]
Sent: Wednesday, October 24, = 2007 6:24=20 AM
To:=20 pcn@ietf.org
Subject: [PCN]=20 PCN & tunnelling

Hi,

 

I was chatting with Bob about section 5.8=20 tunnelling. We’ve realised there’s the following nasty = case which we hadn’t=20 thought about. The scenario is when a tunnel starts inside a = PCN-domain and=20 finishes outside it.

 

First we follow what happens when the = current text=20 is followed. Imagine that the pkt is PCN-marked by some PCN-node = before the=20 tunnel start node. On encapsulation the PCN-mark is copied onto the = outer=20 header. Hence the PCN-egress-node ‘sees’ the PCN-mark as = normal – this is=20 ok. The PCN-egress-node clears the marking in the (outer) header and = forwards the pkt into the next domain. The pkt is decapsulated at = the tunnel=20 end point. But the decapsulated pkt is already PCN-marked. Potential = problems: [1] if it’s decapsulated in a non-PCN-domain, then = the pkt may=20 confuse nodes in this domain [depending on what encoding is used for = a=20 PCN-mark] ; [2] if it’s decapsulated in a PCN-domain, then the = pkt is=20 PCN-marked [which might lead this PCN-domain to terminate or block a = flow=20 unnecessarily].

 

The problem arises because the = PCN-egress-node=20 clears PCN-marking on the outer header but not on the inner header. = (This is=20 a new problem compared with ECN & tunnelling.) =

 

Possible solution: if the pkt is = PCN-marked, then=20 the tunnel start node checks whether the tunnel egress is inside or = outside=20 the PCN-domain - if it’s outside, then it clears the = PCN-marking on the=20 inner header (effectively it does this on behalf of the = PCN-egress-node).=20 (Also, the PCN-mark is copied onto the outer header, as the current = text=20 says.)

 

Thoughts?

 

Thanks,

Phil/=20  

------_=_NextPart_001_01C81A65.F4F8F42C-- --===============0590612827== 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 --===============0590612827==-- From pcn-bounces@ietf.org Mon Oct 29 16:18:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imb46-0001u1-Fn; Mon, 29 Oct 2007 16:18:26 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Imb44-0001sm-Ay for pcn-confirm+ok@megatron.ietf.org; Mon, 29 Oct 2007 16:18:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imb43-0001sT-U7 for pcn@ietf.org; Mon, 29 Oct 2007 16:18:24 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Imb42-0003v9-De for pcn@ietf.org; Mon, 29 Oct 2007 16:18:23 -0400 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 l9TKFO716727; Mon, 29 Oct 2007 20:15:24 GMT x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PCN] Architecture draft - probing section & general updates. Date: Mon, 29 Oct 2007 16:18:12 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB646512DFE23E@zcarhxm1.corp.nortel.com> In-Reply-To: <1B6169C658325341A3B8066E23919E1C4C132A@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Architecture draft - probing section & general updates. Thread-Index: AcgQFh3bpdXKC6/iTqGKgTMqojS39gFKBadgABQhwRAAHsa+UAASrNzAACRENBAA4GGQwA== References: <9671A92C3C8B5744BC97F855F7CB646512CCCEE0@zcarhxm1.corp.nortel.com> <1B6169C658325341A3B8066E23919E1C4C132A@S4DE8PSAANK.mitte.t-com.de> From: "Jozef Babiarz" To: "Geib, Ruediger" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3dfe8a7b5ea10ae7aba70754d4a234d0 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0398014190==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0398014190== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C81A68.D5126577" This is a multi-part message in MIME format. ------_=_NextPart_001_01C81A68.D5126577 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry Ruediger for the delayed response. See below for additional clarifications.=20 Regards, Joe email:babiarz@nortel.com Telephone:613-763-6098 -----Original Message----- From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]=20 Sent: October 25, 2007 5:30 AM To: Babiarz, Jozef (CAR:0S03) Cc: pcn@ietf.org Subject: RE: [PCN] Architecture draft - probing section & general updates. Joe, if I understand you right, the PCN ingress/egress nodes are CPEs=20 (or the like) connected to a single carriers network and this=20 carrier supports PCN. Is that correct? [Joe] What you defined is slightly different but also valid scenario. Sorry if I confused you with "access edge node" I mean edge router/switch within enterprise LAN that hosts, IP phones, etc. connect. While there are many different accesses and a high number=20 access to access communications, each single access carries=20 aggregated traffic from some origins only (but not from all). The accesses probably capture congestion information from WAN=20 links close to them - the number of those usually is=20 restricted and some of the already admitted flows pass them. Without any congestion feedback/indication on ingress or egress - admit the next flow. Otherwise, probing may be useful. My own perception of PCN would be more carrier centric, assuming=20 the PCN edge nodes to be part of the carrier network and not=20 of the customers. But this doesn't necessary invalidate your=20 example. [Joe] My view is that PCN is needed in enterprise and carrier networks and will be deployed by enterprise using tunneling (VPNs) across carrier networks. Regards, Rudiger |-----Original Message----- |From: Jozef Babiarz [mailto:babiarz@nortel.com] |Sent: Wednesday, October 24, 2007 6:14 PM |To: Geib, Rudiger |Cc: pcn@ietf.org |Subject: RE: [PCN] Architecture draft - probing section & general |updates. | | |Ruediger,=20 |I'm thinking of a scenario that many enterprises face today.=20 |Large multi |location enterprises use multiple WAN links or VPS to=20 |interconnect their |locations. PCN is run inside the enterprise network including WAN links |which maybe tunneled across the carrier network. Network Access Control |with PCN admission control is done at the enterprise access edge nodes. |New flows can be routed to any egress access edge node and some flows |will (between different locations) be routed over one of the WAN links |which are normally bandwidth constrained. There is a high probability |that many access nodes will only have one flow between each other as |there are a large number of them. | |Regards, Joe |email:babiarz@nortel.com |Telephone:613-763-6098 | |-----Original Message----- |From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]=20 |Sent: October 24, 2007 3:04 AM |To: Babiarz, Jozef (CAR:0S03) |Cc: pcn@ietf.org |Subject: RE: [PCN] Architecture draft - probing section & general |updates. | |Joe, | |my perception is, that probing may be useful, once there is=20 |pre-congestion. In a situation without a single admitted=20 |flow between an ingress and an egress, if neither ingress=20 |node nor egress node have any indication of pre-congestion=20 |on any of the links crossed by the PCN flows passing through=20 |them, there's with high probability no need to probe,=20 |I'd assume. I don't do simulations and would like to invite |those simulating to come up with cases where this assumption=20 |is wrong. | |I'd further propose to collect information from providers=20 |on the probability of the event you describe.=20 | |Regards,=20 | |Rudiger | ||-----Original Message----- ||From: Jozef Babiarz [mailto:babiarz@nortel.com] ||Sent: Tuesday, October 23, 2007 6:22 PM ||To: Geib, Rudiger; philip.eardley@bt.com ||Cc: pcn@ietf.org ||Subject: RE: [PCN] Architecture draft - probing section & general ||updates. || || ||Ruediger, the issue is not addition of one more flow into the=20 |link that ||is experiencing (pre-)congestion level for admission but potentially ||hundreds of new ingress-egress aggregates that have not been=20 ||established ||passing through the link.=20 || ||Regards, Joe ||email:babiarz@nortel.com ||Telephone:613-763-6098 || ||-----Original Message----- ||From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]=20 ||Sent: October 23, 2007 4:19 AM ||To: philip.eardley@bt.com ||Cc: pcn@ietf.org ||Subject: RE: [PCN] Architecture draft - probing section & general ||updates. || ||Phil, || ||I appreciate that probing is optional. I understand that to mean that ||standardisation allows to operate PCN within a domain without=20 |having to ||support any probing functionality. || ||There may be operational conditions, when probing makes=20 |sense. This may ||be the case, if the number of multiplexed flows is at the=20 ||lower bound of ||the range where statistical multiplexing can be applied on=20 |any link and ||the number of possible ingress to egress relations passing=20 |this link is ||big enough to lead to (pre-)congestion by admission of a single flow ||with a reasonable probability. I don't want to stop people=20 |from working ||on this issue, but I'd favour PCN to finish standards for an=20 ||operational ||environment where the probability of a single admitted flow causing ||congestion on a link is extremly low.=20 || ||Regards, || ||Rudiger || || ||_______________________________________________ ||PCN mailing list ||PCN@ietf.org ||https://www1.ietf.org/mailman/listinfo/pcn || | ------_=_NextPart_001_01C81A68.D5126577 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [PCN] Architecture draft - probing section & general = updates.

Sorry Ruediger for the delayed response. See below for additional clarifications. =

Regards, Joe

email:babiarz@nortel.com

Telephone:613-763-6098

-----Original Message-----
From: Geib, Ruediger [mailto:Ruediger.Geib@t-system= s.com]
Sent: October 25, 2007 5:30 AM
To: Babiarz, Jozef (CAR:0S03)
Cc: pcn@ietf.org
Subject: RE: [PCN] Architecture draft - probing section & general = updates.

Joe,

if = I understand you right, the PCN ingress/egress nodes are CPEs =

(or the like) connected to a single carriers network and this =

carrier supports PCN. Is that correct?

[Joe] What you defined is slightly different but also = valid scenario. Sorry if = I confused you with "access = edge node" I mean edge router/switch within enterprise LAN that = hosts, IP phones, etc. = connect.

While there are many different accesses and a high number =

access to access communications, each single access carries =

aggregated traffic from some origins only (but not from = all).

The accesses probably capture congestion information from WAN =

links close to them - the number of those usually is =

restricted and some of the already admitted flows pass = them.

Without any congestion feedback/indication on ingress or = egress

- = admit the next flow. Otherwise, probing may be useful.

My = own perception of PCN would be more carrier centric, assuming =

the PCN edge nodes to be part of the carrier network and not =

of = the customers. But this doesn't necessary invalidate your =

example.

[Joe] My view is that = PCN is needed in enterprise and = carrier networks and will be deployed by = enterprise using tunneling (VPNs) across carrier = networks.

Regards,

Rudiger


|-----Original Message-----

|From: Jozef Babiarz [mailto:babiarz@nortel.com]<= /SPAN>

|Sent: Wednesday, October 24, 2007 6:14 PM

|To: Geib, Rudiger

|Cc: pcn@ietf.org

|Subject: RE: [PCN] Architecture draft - probing section & = general

|updates.

|

|

|Ruediger,

|I'm thinking of a scenario that many enterprises face today. =

|Large multi

|location enterprises use multiple WAN links or VPS to =

|interconnect their

|locations. PCN is run inside the enterprise network including WAN = links

|which maybe tunneled across the carrier network. Network Access = Control

|with PCN admission control is done at the enterprise access edge = nodes.

|New flows can be routed to any egress access edge node and some = flows

|will (between different locations) be routed over one of the WAN = links

|which are normally bandwidth constrained. There is a high = probability

|that many access nodes will only have one flow between each other = as

|there are a large number of them.

|

|Regards, Joe

|email:babiarz@nortel.com

|Telephone:613-763-6098

|

|-----Original Message-----

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

|Sent: October 24, 2007 3:04 AM

|To: Babiarz, Jozef (CAR:0S03)

|Cc: pcn@ietf.org

|Subject: RE: [PCN] Architecture draft - probing section & = general

|updates.

|

|Joe,

|

|my perception is, that probing may be useful, once there is =

|pre-congestion. In a situation without a single admitted =

|flow between an ingress and an egress, if neither ingress =

|node nor egress node have any indication of pre-congestion =

|on any of the links crossed by the PCN flows passing through =

|them, there's with high probability no need to probe, =

|I'd assume. I don't do simulations and would like to = invite

|those simulating to come up with cases where this assumption =

|is wrong.

|

|I'd further propose to collect information from providers =

|on the probability of the event you describe.

|

|Regards,

|

|Rudiger

|

||-----Original Message-----

||From: Jozef Babiarz [mailto:babiarz@nortel.com]<= /SPAN>

||Sent: Tuesday, October 23, 2007 6:22 PM

||To: Geib, Rudiger; philip.eardley@bt.com

||Cc: pcn@ietf.org

||Subject: RE: [PCN] Architecture draft - probing section & = general

||updates.

||

||

||Ruediger, the issue is not addition of one more flow into the =

|link that

||is experiencing (pre-)congestion level for admission but = potentially

||hundreds of new ingress-egress aggregates that have not been =

||established

||passing through the link.

||

||Regards, Joe

||email:babiarz@nortel.com

||Telephone:613-763-6098

||

||-----Original Message-----

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

||Sent: October 23, 2007 4:19 AM

||To: philip.eardley@bt.com

||Cc: pcn@ietf.org

||Subject: RE: [PCN] Architecture draft - probing section & = general

||updates.

||

||Phil,

||

||I appreciate that probing is optional. I understand that to mean = that

||standardisation allows to operate PCN within a domain without =

|having to

||support any probing functionality.

||

||There may be operational conditions, when probing makes =

|sense. This may

||be the case, if the number of multiplexed flows is at the =

||lower bound of

||the range where statistical multiplexing can be applied on =

|any link and

||the number of possible ingress to egress relations passing =

|this link is

||big enough to lead to (pre-)congestion by admission of a single = flow

||with a reasonable probability. I don't want to stop people =

|from working

||on this issue, but I'd favour PCN to finish standards for an =

||operational

||environment where the probability of a single admitted flow = causing

||congestion on a link is extremly low.

||

||Regards,

||

||Rudiger

||

||

||_______________________________________________

||PCN mailing list

||PCN@ietf.org

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

||

|

------_=_NextPart_001_01C81A68.D5126577-- --===============0398014190== 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 --===============0398014190==-- From pcn-bounces@ietf.org Mon Oct 29 17:06:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imbo5-00077g-UX; Mon, 29 Oct 2007 17:05:57 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Imbo5-00076t-61 for pcn-confirm+ok@megatron.ietf.org; Mon, 29 Oct 2007 17:05:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imbo4-00076j-Qd for pcn@ietf.org; Mon, 29 Oct 2007 17:05:56 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Imbo4-0007q2-Cm for pcn@ietf.org; Mon, 29 Oct 2007 17:05:56 -0400 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l9TL5fI21333; Mon, 29 Oct 2007 21:05:41 GMT x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Architecture draft - probing section & general updates. Date: Mon, 29 Oct 2007 17:05:36 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB646512DFE32B@zcarhxm1.corp.nortel.com> In-Reply-To: <9EE2BE22-5E19-4625-B368-3A603728ED52@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Architecture draft - probing section & general updates. Thread-Index: AcgW7SC2PEVcOi1+Qg+vZ1UxgSPGoQDfIixA References: <9671A92C3C8B5744BC97F855F7CB646512C6F7D0@zcarhxm1.corp.nortel.com> <1B6169C658325341A3B8066E23919E1C0DE91D@S4DE8PSAANK.mitte.t-com.de> <9671A92C3C8B5744BC97F855F7CB646512CCCEE0@zcarhxm1.corp.nortel.com> <9EE2BE22-5E19-4625-B368-3A603728ED52@nokia.com> From: "Jozef Babiarz" To: "Lars Eggert" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: pcn@ietf.org, "Geib, Ruediger" X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Lars,=20 I did not explain my scenario that clearly, I confused people the word "access node". So here goes a second try. I'm thinking of a scenario that many enterprises face today. Large multi location enterprises use multiple WAN links or VPS to interconnect their locations (branch offices). PCN is run inside the enterprise network including WAN links which may be tunneled across the carrier network. Carrier network is not required to support PCN as the enterprise traffic including PCN marking is tunneled, however it could. Network Access Control with PCN admission control is done at the *enterprise* LAN edge switch/router. New flows can be routed to any egress LAN edge switch/router and some flows will (between different locations) be routed over one of the WAN links which are normally bandwidth constrained. There is a high probability that many of the edge LAN switches/routers will have no flows setup between each other (no ingress-egress aggregate) as there are a large number of edge LAN switches/routers in the enterprise network and people calling patterns change. They normal expect that they should be able to call anyone. Regards, Joe email:babiarz@nortel.com Telephone:613-763-6098 -----Original Message----- From: Lars Eggert [mailto:lars.eggert@nokia.com]=20 Sent: October 25, 2007 5:54 AM To: Babiarz, Jozef (CAR:0S03) Cc: Geib, Ruediger; pcn@ietf.org Subject: Re: [PCN] Architecture draft - probing section & general updates. On 2007-10-24, at 19:14, ext Jozef Babiarz wrote: > I'm thinking of a scenario that many enterprises face today. Large =20 > multi > location enterprises use multiple WAN links or VPS to interconnect =20 > their > locations. PCN is run inside the enterprise network including WAN =20 > links > which maybe tunneled across the carrier network. Network Access =20 > Control > with PCN admission control is done at the enterprise access edge =20 > nodes. > New flows can be routed to any egress access edge node and some flows > will (between different locations) be routed over one of the WAN links > which are normally bandwidth constrained. I understand your scenario so far. > There is a high probability > that many access nodes will only have one flow between each other as > there are a large number of them. I don't see how this follows, however. It seems that if the sites =20 that are being interconnected aren't tiny, there should very likely =20 be multiple flows per ingress/egress pair, no? Lars _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Oct 30 05:18:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImnES-00027S-7y; Tue, 30 Oct 2007 05:17:56 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1ImnER-00026X-AS for pcn-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 05:17:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImnER-00026P-0w for pcn@ietf.org; Tue, 30 Oct 2007 05:17:55 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImnEK-000067-NE for pcn@ietf.org; Tue, 30 Oct 2007 05:17:55 -0400 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Tue, 30 Oct 2007 10:17:38 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Oct 2007 10:17:38 +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] Architecture draft - probing section & general updates. Date: Tue, 30 Oct 2007 10:17:37 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1C4C1390@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <9671A92C3C8B5744BC97F855F7CB646512DFE32B@zcarhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Architecture draft - probing section & general updates. Thread-Index: AcgW7SC2PEVcOi1+Qg+vZ1UxgSPGoQDfIixAABpXZpA= From: "Geib, Ruediger" To: X-OriginalArrivalTime: 30 Oct 2007 09:17:38.0165 (UTC) FILETIME=[B70F5250:01C81AD5] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hello Joe, Thanks for your clarification. |locations (branch offices). PCN is run inside the enterprise network |including WAN links which may be tunneled across the carrier network. |Carrier network is not required to support PCN as the enterprise traffic |including PCN marking is tunneled, however it could. =20 I'm more interested in a PCN scenario interconnecting carrier application=20 servers or edge nodes. That way, sufficiently high numbers of flows may=20 result to have a relatively good perception of the congestion status=20 of the network. Corporate networks allow for any to any communication, but the question is,=20 whether all are used for it. Within my own corporation, I largely=20 communicate with 4 centers and randomly call say 6 other destinations, one=20 of which is outside of my home country. My company is active worldwide and=20 has a huge number of PoPs. Most of my colleagues have similar communication=20 patterns. Regards, Rudiger _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Oct 30 05:33:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImnTL-00083I-GI; Tue, 30 Oct 2007 05:33:19 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1ImnTJ-000832-Na for pcn-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 05:33:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImnTJ-00082u-Dp for pcn@ietf.org; Tue, 30 Oct 2007 05:33:17 -0400 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImnTC-0000to-W5 for pcn@ietf.org; Tue, 30 Oct 2007 05:33:17 -0400 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 09:33:07 +0000 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 30 Oct 2007 09:32:18 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B342AA@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New version of draft-ietf-pcn-architecture Thread-Index: Acga18OF5DILCk3BREOSAM1xqYRr4Q== From: To: X-OriginalArrivalTime: 30 Oct 2007 09:33:07.0229 (UTC) FILETIME=[E0D33CD0:01C81AD7] X-Spam-Score: 0.0 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Subject: [PCN] New version of draft-ietf-pcn-architecture X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1004742763==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1004742763== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C81AD7.C3D6934C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C81AD7.C3D6934C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I updated the architecture draft to reflect the comments over the last couple of months.=20 http://www.ietf.org/internet-drafts/draft-ietf-pcn-architecture-01.txt=20 =20 Comments please! =20 * the doc aims to fulfil our Milestone of an Info doc on 'Flow Admission and Termination Architecture within a Diffserv Domain' (due Nov 07). What improvements does it need in order to meet this Milestone? * are there any missing topics that need to be covered? * should the introduction be longer, eg to explain the background more? * the OAM section is a known weakness, I'll re-issue the draft if this section gets improved before the Vancouver I-D deadline. (Bob volunteered to re-write it.) * what needs to be improved /changed for the I-D to be ready for WG last call? (Personally I think it's quite close to being ready.) =20 thanks! phil/=20 =20 ------_=_NextPart_001_01C81AD7.C3D6934C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I updated the architecture draft to reflect = the comments over the last couple of months.

http://www.ietf.org/internet-drafts/draft-ietf-pcn-architecture-01= .txt

 

Comments please!

 

* the doc aims to fulfil our Milestone of an = Info doc on 'Flow Admission and Termination Architecture within a Diffserv = Domain' (due Nov 07). What improvements does it need in order to meet this = Milestone?

* are there any missing topics that need to = be covered?

* should the introduction be longer, eg to = explain the background more?

* the OAM section is a known weakness, I’ll re-issue the = draft if this section gets improved before the Vancouver I-D deadline. (Bob = volunteered to re-write it.)

* what needs to be improved /changed for the I-D to be ready for = WG last call? (Personally I think it’s quite close to being = ready.)

 

thanks!

phil/

 

=00 ------_=_NextPart_001_01C81AD7.C3D6934C-- --===============1004742763== 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 --===============1004742763==-- From pcn-bounces@ietf.org Tue Oct 30 10:49:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImsOi-0005dp-4q; Tue, 30 Oct 2007 10:48:52 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1ImsOg-0005WS-IW for pcn-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 10:48:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImsOg-0005BM-8i for pcn@ietf.org; Tue, 30 Oct 2007 10:48:50 -0400 Received: from smtp3.smtp.bt.com ([217.32.164.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImsOS-00073z-Nm for pcn@ietf.org; Tue, 30 Oct 2007 10:48:44 -0400 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 14:48:12 +0000 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 30 Oct 2007 14:48:07 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B342AE@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: traffic matrix scenario Thread-Index: AcgbA+IAhc9rfEAcTjSuKU0GO02DLw== From: To: X-OriginalArrivalTime: 30 Oct 2007 14:48:12.0019 (UTC) FILETIME=[E4F54430:01C81B03] X-Spam-Score: -1.0 (-) X-Scan-Signature: 748ed3980abc7d4bd6a14905626ff64e Subject: [PCN] traffic matrix scenario X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0725307967==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0725307967== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C81B03.E224EAC5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C81B03.E224EAC5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi =20 Ben & I have made some estimates, based on a future busy hour for a national network with about 100 PCN-boundary-nodes. We assume that the case of interest is where the traffic follows this normal pattern and that the network is (becoming) pre-congested due to a massive surge of traffic outside this traffic pattern.=20 =20 Our estimate is that 3/4 of ingress-egress-aggregates will have traffic of less than 1.5 Erlang. The distribution is long-tailed, for example there are several ingress-egress-aggregates with > 4000 Erlangs. =20 We have made some speculations about how this translates into traffic on particular interfaces. The topology of the network has each PCN-boundary-node attached to 2 different PCN-interior-nodes; PCN-interior-nodes are more interconnected (> dual-homed).=20 So for a particular PCN-boundary-node to PCN-interior-node interface, it potentially has 50 ingress-egress-aggregates on it; we estimate that actually 25 of these will not have a flow, 10 will have 1 and 15 will have >1. For a PCN-interior-node to PCN-interior-node interface, the topology suggests potentially 300 ingress-egress-aggregates on it; the fractions are the same as before, ie we estimate that actually 150 of these will not have a flow, 60 will have 1 and 90 will have >1. =20 We re-iterate that these are very rough estimates. But they strongly suggest that there are likely to be significant numbers of aggregates with very few flows under nearly all circumstances. =20 =20 Best wishes, Phil & Ben > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@nokia.com] > Sent: 25 October 2007 13:25 > To: Eardley,PL,Philip,CXR9 R > Cc: babiarz@nortel.com; pcn@ietf.org; Ruediger.Geib@t-systems.com > Subject: Re: [PCN] Architecture draft - probing section & general updates. >=20 > On 2007-10-25, at 13:56, ext philip.eardley@bt.com wrote: > > Lars, I believe the guess is that there'll be many ingress-egress=20 > > pairs with none or very few flows at a particular moment. Not a=20 > > random distribution of calls onto all possible pairs. Basically=20 > > there are many calls between London & Manchester and very few=20 > > between truro and Shetland. >=20 > I can agree with that. But note that that alone is not a problem yet. >=20 > The problem occurs only when several of these "empty" ingress pairs=20 > share a bottleneck *and* when single flows start simultaneously=20 > sending across them at a combined rate that will push the bottleneck=20 > directly into overload. >=20 > I don't believe this can be very common. Wouldn't you provision your=20 > network such that interior routers could handle at least one flow per=20 > ingress/egress pair? In which case there is no issue unless there's a=20 > failure. And why not let flow termination handle these rare cases? >=20 > > I & Ben will try and extract some numbers from the [bt] predicted=20 > > future traffic matrix. >=20 > That'd be *very* useful! We're all guessing probabilities here, and=20 > data would help. >=20 > Lars =20 =20 ------_=_NextPart_001_01C81B03.E224EAC5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi

 

Ben & I have made some estimates, based on a future busy = hour for a national network with about 100 PCN-boundary-nodes. We assume that the = case of interest is where the traffic follows this normal pattern and that the = network is (becoming) pre-congested due to a massive surge of traffic outside = this traffic pattern.

 

Our estimate is that 3/4 of ingress-egress-aggregates will have = traffic of less than 1.5 Erlang. The distribution is long-tailed, for example = there are several ingress-egress-aggregates with > 4000 = Erlangs.

 

We have made some speculations about how this translates into = traffic on particular interfaces. The topology of the network has each PCN-boundary-node attached to 2 different PCN-interior-nodes; PCN-interior-nodes are more interconnected (> dual-homed). =

So for a particular PCN-boundary-node to PCN-interior-node = interface, it potentially has 50 ingress-egress-aggregates on it; we estimate that actually 25 of these will not have a flow, 10 will have 1 and 15 will = have >1.

For a PCN-interior-node to PCN-interior-node interface, the = topology suggests potentially 300 ingress-egress-aggregates on it; the fractions = are the same as before, ie we estimate that actually 150 of these will not have = a flow, 60 will have 1 and 90 will have >1.

 

We = re-iterate that these are very rough estimates. But they strongly suggest that = there are likely to be significant numbers of aggregates with very few flows under = nearly all circumstances.

 

 

Best wishes,

Phil & Ben

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

> From: Lars Eggert = [mailto:lars.eggert@nokia.com]

> Sent: 25 October 2007 13:25

> To: Eardley,PL,Philip,CXR9 R

> Cc: babiarz@nortel.com; pcn@ietf.org; Ruediger.Geib@t-systems.com

> Subject: Re: [PCN] Architecture draft - probing section = & general updates.

>

> On 2007-10-25, at 13:56, ext = philip.eardley@bt.com wrote:

> > Lars, I believe the guess is that there'll be many = ingress-egress

> > pairs with none or very few flows at a particular = moment. Not a

> > random distribution of calls onto all possible pairs. Basically

> > there are many calls between London = & Manchester and very few

> > between truro and Shetland.

>

> I can agree with that. But note that that alone is not a = problem yet.

>

> The problem occurs only when several of these = "empty" ingress pairs

> share a bottleneck *and* when single flows start = simultaneously

> sending across them at a combined rate that will push the bottleneck

> directly into overload.

>

> I don't believe this can be very common. Wouldn't you = provision your

> network such that interior routers could handle at least = one flow per

> ingress/egress pair? In which case there is no issue unless there's a

> failure. And why not let flow termination handle these rare = cases?

>

> > I & Ben will try and extract some numbers from the = [bt] predicted

> > future traffic matrix.

>

> That'd be *very* useful! We're all guessing probabilities = here, and

> data would help.

>

> Lars

 

 

=00 ------_=_NextPart_001_01C81B03.E224EAC5-- --===============0725307967== 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 --===============0725307967==-- From pcn-bounces@ietf.org Wed Oct 31 04:12:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In8fj-0000xk-Vc; Wed, 31 Oct 2007 04:11:31 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1In8fi-0000vk-KH for pcn-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 04:11:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In8fd-0000kO-HY; Wed, 31 Oct 2007 04:11:25 -0400 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 1In8fX-00070y-5T; Wed, 31 Oct 2007 04:11:25 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9V8B51H019816; Wed, 31 Oct 2007 10:11:12 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 10:11:07 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 10:11:07 +0200 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 10:11:06 +0200 Received: from [172.21.35.97] (esdhcp03597.research.nokia.com [172.21.35.97]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9V8B5lc027987; Wed, 31 Oct 2007 10:11:05 +0200 In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B342AE@E03MVZ1-UKDY.domain1.systemhost.net> References: <75A199C5D243C741BF3D3F1EBCEF9BA503B342AE@E03MVZ1-UKDY.domain1.systemhost.net> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <3AD8370E-3CA4-48D7-9BC8-426ECC7BA320@nokia.com> Cc: From: Lars Eggert Subject: Re: [PCN] traffic matrix scenario Date: Wed, 31 Oct 2007 10:11:03 +0200 To: "ext pcn-bounces@ietf.org" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 31 Oct 2007 08:11:06.0967 (UTC) FILETIME=[96889670:01C81B95] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1901104839==" Errors-To: pcn-bounces@ietf.org --===============1901104839== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-35-762699340; protocol="application/pkcs7-signature" --Apple-Mail-35-762699340 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-10-30, at 16:48, ext pcn-bounces@ietf.org wrote: > We re-iterate that these are very rough estimates. But they strongly > suggest that there are likely to be significant numbers of aggregates > with very few flows under nearly all circumstances. But this only means that there is a *potential* for a problem. Do you have an estimate on how likely it is that a sufficient number of new flows start transmitting over these empty aggregates at roughly the same time, such that they together can push the bottleneck straight into overload? Lars --Apple-Mail-35-762699340 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzEwMzEwODExMDRaMCMGCSqGSIb3DQEJBDEWBBRgCkGHAIr5jNyP caUZCikRk2kHeDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEA2gtBpN54OCsV7uvIHjp5uyZallzPbmZgpuE//GrQvigS469ofN8+ 6ZAhQRIEYbumQISw+xB06D6YLL/M/oiWj4oWxIcsyQVbHWCM0b6HwFVc4L3sssjoukxvpHLOc+OV qf7QNgScGNwra59RTA6NQ1QUPu8DfQpBBPknBfg4eOTbSZC9269IrGh7j3vCr/kRN1aMgjS4e1k6 ZClJMx+t/0e+7ean3Lplr8LUnPtuzEopZZtvakmM2/KKm9hzpwqw0kMKCoTvPenHvrVrQJcVxCV6 7nnFJJADlF+2xWG1xPzqn41m6SK3o0qM7eZodYHOxGIrL61mWvSUZyBkkg5YoAAAAAAAAA== --Apple-Mail-35-762699340-- --===============1901104839== 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 --===============1901104839==-- From pcn-bounces@ietf.org Wed Oct 31 06:37:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InAx0-00071d-1l; Wed, 31 Oct 2007 06:37:30 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1InAwz-00071V-7p for pcn-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 06:37:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InAwy-00071C-Ru for pcn@ietf.org; Wed, 31 Oct 2007 06:37:28 -0400 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InAwy-00060f-BE for pcn@ietf.org; Wed, 31 Oct 2007 06:37:28 -0400 Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 10:37:27 +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] traffic matrix scenario Date: Wed, 31 Oct 2007 10:37:26 -0000 Message-ID: <66C55C26FA491C42A9C9BB62A376DAFF015ED66A@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <3AD8370E-3CA4-48D7-9BC8-426ECC7BA320@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] traffic matrix scenario Thread-Index: AcgblgBwA5JkK5klSC+Vpq47uI0BdgAEOZgg From: To: X-OriginalArrivalTime: 31 Oct 2007 10:37:27.0207 (UTC) FILETIME=[07F6E370:01C81BAA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Lars, All=20 > But this only means that there is a *potential* for a problem. >=20 > Do you have an estimate on how likely it is that a sufficient=20 > number of new flows start transmitting over these empty=20 > aggregates at roughly the same time, such that they together=20 > can push the bottleneck straight into overload? We cannot really give any measure of likelihood. In this deployment scenario, at least, we design our network so PCN almost never rejects calls unless the traffic matrix is highly anomalous. Such anomalies are inherently unpredictable. For example, a scenario we sometimes consider is an event which simultaneously destroys an exchange building and causes a surge of traffic to and from the affected exchange region consisting of emergency traffic mixed with concerned relatives calling up to see what has happened. We cannot tell you how likely this scenario is. But it is essential to us that PCN operates correctly in this scenario, regardless of the scenario's precise likelihood. So, what do we need to do to ensure that PCN does operate correctly in the presence of extreme anomalous events? =20 We have a few parameters to play with. One is the margin between pre-congestion and actual congestion. Another is provided by a cap on the rate of admitting new flows. What the statistics we gave before imply is that this rate must be quite tightly capped, at least in the case of ingress-egress aggregates with no flows, because the size of the pulse of flows we admit before we get good feedback could be being multiplied across many other ingresses, and together this chunk of admissions must be reliably limited to below our safety margin. If the rate of admission is being capped on a per ingress basis, then the multiplication factor cannot reliably be assumed to be much smaller than the total number of ingresses, 100 in our case. If the rate of admission is being capped on a per aggregate basis then our traffic matrix information suggests that we could have a situation where many aggregates (a few thousand) are all ramping up into the same bottleneck. So the multiplication factor needs to be of that order. We can do the sums: given the safety margin, the time lag before feedback becomes reliable, and the multiplication factor we can directly compute the maximum rate of admission per ingress and per aggregate. Alternatively, given a desirable minimum size for this maximum rate of admission we can compute the needed safety margin. What should we take to be the time lag before the feedback becomes reliable? One component is the amount of time between admission control decision and data actually reaching the ingress. Can we assume this to be reliably bounded? The other components are then propagation and queueing delay, alongside the time needed for the bottleneck queues to grow and the congestion estimates to grow. Do we have good estimates for these times?=20 Ben Strulo _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Oct 31 06:59:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InBI2-00085d-O2; Wed, 31 Oct 2007 06:59:14 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1InBI0-0007xP-77 for pcn-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 06:59:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InBHz-0007uh-P5 for pcn@ietf.org; Wed, 31 Oct 2007 06:59:11 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InBHn-0006vY-Ee for pcn@ietf.org; Wed, 31 Oct 2007 06:59:00 -0400 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Wed, 31 Oct 2007 11:58:48 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 31 Oct 2007 11:58:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] traffic matrix scenario Date: Wed, 31 Oct 2007 11:58:47 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1C4C13AF@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <66C55C26FA491C42A9C9BB62A376DAFF015ED66A@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] traffic matrix scenario Thread-Index: AcgblgBwA5JkK5klSC+Vpq47uI0BdgAEOZggAAERqLA= From: "Geib, Ruediger" To: X-OriginalArrivalTime: 31 Oct 2007 10:58:48.0265 (UTC) FILETIME=[0388D390:01C81BAD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Ben, thanks, your text nicely explains things. On the dimension of the time lag, I'm not favouring to dimension the lag for a situation where just admitting the new flow results in pre-congestion marking. This will result in a rather long lag. I'd rather like to make sure, that if there's congestion already and another flow is admitted, then there should be no new admission. That would assume that with the first packets of the admitted flow, pre congestion marked packets are received. It may be useful to have separate timers: - absolutely no pre congestion indication on ingress or egress * the lag is rather short or zero - pre-congestion indicated on the ingress or egress, but=20 not for the lately admitted flow * the lag is somewhat bigger - pre-congestion indicated (no matter which amount) for the=20 lately admitted flow * no new admission prior to a full PCN pre congestion=20 feedback cycle on that flows ingress/egress relation. Regards, Rudiger =20 |-----Original Message----- |From: ben.strulo@bt.com [mailto:ben.strulo@bt.com] |Sent: Wednesday, October 31, 2007 11:37 AM |To: lars.eggert@nokia.com |Cc: pcn@ietf.org |Subject: RE: [PCN] traffic matrix scenario | | |Lars, All=20 | |> But this only means that there is a *potential* for a problem. |>=20 |> Do you have an estimate on how likely it is that a sufficient=20 |> number of new flows start transmitting over these empty=20 |> aggregates at roughly the same time, such that they together=20 |> can push the bottleneck straight into overload? | |We cannot really give any measure of likelihood. In this deployment |scenario, at least, we design our network so PCN almost never rejects |calls unless the traffic matrix is highly anomalous. Such=20 |anomalies are |inherently unpredictable. For example, a scenario we=20 |sometimes consider |is an event which simultaneously destroys an exchange building and |causes a surge of traffic to and from the affected exchange region |consisting of emergency traffic mixed with concerned relatives calling |up to see what has happened. We cannot tell you how likely this |scenario is. But it is essential to us that PCN operates correctly in |this scenario, regardless of the scenario's precise likelihood. | |So, what do we need to do to ensure that PCN does operate correctly in |the presence of extreme anomalous events? =20 |We have a few parameters to play with. One is the margin between |pre-congestion and actual congestion. Another is provided by a cap on |the rate of admitting new flows. | |What the statistics we gave before imply is that this rate=20 |must be quite |tightly capped, at least in the case of ingress-egress aggregates with |no flows, because the size of the pulse of flows we admit before we get |good feedback could be being multiplied across many other=20 |ingresses, and |together this chunk of admissions must be reliably limited to below our |safety margin. If the rate of admission is being capped on a per |ingress basis, then the multiplication factor cannot reliably=20 |be assumed |to be much smaller than the total number of ingresses, 100 in our case. |If the rate of admission is being capped on a per aggregate basis then |our traffic matrix information suggests that we could have a situation |where many aggregates (a few thousand) are all ramping up into the same |bottleneck. So the multiplication factor needs to be of that order. | |We can do the sums: given the safety margin, the time lag before |feedback becomes reliable, and the multiplication factor we=20 |can directly |compute the maximum rate of admission per ingress and per aggregate. |Alternatively, given a desirable minimum size for this maximum rate of |admission we can compute the needed safety margin. | |What should we take to be the time lag before the feedback becomes |reliable? One component is the amount of time between=20 |admission control |decision and data actually reaching the ingress. Can we assume this to |be reliably bounded? The other components are then propagation and |queueing delay, alongside the time needed for the bottleneck queues to |grow and the congestion estimates to grow. Do we have good estimates |for these times?=20 | |Ben Strulo | | |_______________________________________________ |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 Oct 31 07:13:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InBVc-00034S-QW; Wed, 31 Oct 2007 07:13:16 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1InBVb-00033v-3a for pcn-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 07:13:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InBVa-000331-GK for pcn@ietf.org; Wed, 31 Oct 2007 07:13:14 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InBVU-0007Pv-Ur for pcn@ietf.org; Wed, 31 Oct 2007 07:13:14 -0400 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Wed, 31 Oct 2007 12:12:59 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 31 Oct 2007 12:12:59 +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] traffic matrix scenario Date: Wed, 31 Oct 2007 12:12:58 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1C4C13B0@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B342AE@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: traffic matrix scenario Thread-Index: AcgbA+IAhc9rfEAcTjSuKU0GO02DLwAlhhvw From: "Geib, Ruediger" To: X-OriginalArrivalTime: 31 Oct 2007 11:12:59.0562 (UTC) FILETIME=[FEF270A0:01C81BAE] X-Spam-Score: -1.0 (-) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Phil, I'd like to return to my point, that probing is only required if there's any pre-congestion in the network. The question now is, what's the probability, that two end points try to set up a first flow between them and none of both is aware of pre-congestion, which is already on one of the links to be crossed by that flow. The congestion isn't on the boundary to interior links (then either ingress or egress node receive pre-congestion marked packets or receive feedback on them). Hence you look for a pre-congested interior link which isn't crossed by any flow to or from the boundary nodes trying to set up a new flow. As this link is pre-congested, there's a heavy demand between many other end points, but the link is not used by a single flow of the end points trying to set up the new flow. That's the situation when you may admit a flow on a link which is already in pre congestion mode.=20 As mentioned in my other mail, I don't think we should try to measure whether a new flow would push an aggregate to pre-congestion mode. I regard this case as standard operation, the decision should always be: admit. Regards, Rudiger -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: Tuesday, October 30, 2007 3:48 PM To: pcn@ietf.org Subject: [PCN] traffic matrix scenario Hi Ben & I have made some estimates, based on a future busy hour for a national network with about 100 PCN-boundary-nodes. We assume that the case of interest is where the traffic follows this normal pattern and that the network is (becoming) pre-congested due to a massive surge of traffic outside this traffic pattern.=20 Our estimate is that 3/4 of ingress-egress-aggregates will have traffic of less than 1.5 Erlang. The distribution is long-tailed, for example there are several ingress-egress-aggregates with > 4000 Erlangs. We have made some speculations about how this translates into traffic on particular interfaces. The topology of the network has each PCN-boundary-node attached to 2 different PCN-interior-nodes; PCN-interior-nodes are more interconnected (> dual-homed).=20 So for a particular PCN-boundary-node to PCN-interior-node interface, it potentially has 50 ingress-egress-aggregates on it; we estimate that actually 25 of these will not have a flow, 10 will have 1 and 15 will have >1. For a PCN-interior-node to PCN-interior-node interface, the topology suggests potentially 300 ingress-egress-aggregates on it; the fractions are the same as before, ie we estimate that actually 150 of these will not have a flow, 60 will have 1 and 90 will have >1. We re-iterate that these are very rough estimates. But they strongly suggest that there are likely to be significant numbers of aggregates with very few flows under nearly all circumstances. Best wishes, Phil & Ben > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@nokia.com] > Sent: 25 October 2007 13:25 > To: Eardley,PL,Philip,CXR9 R > Cc: babiarz@nortel.com; pcn@ietf.org; Ruediger.Geib@t-systems.com > Subject: Re: [PCN] Architecture draft - probing section & general updates. >=20 > On 2007-10-25, at 13:56, ext philip.eardley@bt.com wrote: > > Lars, I believe the guess is that there'll be many ingress-egress=20 > > pairs with none or very few flows at a particular moment. Not a=20 > > random distribution of calls onto all possible pairs. Basically=20 > > there are many calls between London & Manchester and very few=20 > > between truro and Shetland. >=20 > I can agree with that. But note that that alone is not a problem yet. >=20 > The problem occurs only when several of these "empty" ingress pairs=20 > share a bottleneck *and* when single flows start simultaneously=20 > sending across them at a combined rate that will push the bottleneck=20 > directly into overload. >=20 > I don't believe this can be very common. Wouldn't you provision your=20 > network such that interior routers could handle at least one flow per=20 > ingress/egress pair? In which case there is no issue unless there's a=20 > failure. And why not let flow termination handle these rare cases? >=20 > > I & Ben will try and extract some numbers from the [bt] predicted=20 > > future traffic matrix. >=20 > That'd be *very* useful! We're all guessing probabilities here, and=20 > data would help. >=20 > Lars _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Oct 31 07:49:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InC4C-0002UH-Pk; Wed, 31 Oct 2007 07:49:00 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1InC4C-0002UB-1x for pcn-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 07:49:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InC4B-0002Tx-EH for pcn@ietf.org; Wed, 31 Oct 2007 07:48:59 -0400 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 1InC45-0000aI-KV for pcn@ietf.org; Wed, 31 Oct 2007 07:48:59 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9VBmj4S032408; Wed, 31 Oct 2007 13:48:45 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 13:48:38 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 13:48:37 +0200 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 13:48:37 +0200 Received: from [172.21.35.97] (esdhcp03597.research.nokia.com [172.21.35.97]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9VBmZnw004205; Wed, 31 Oct 2007 13:48:35 +0200 In-Reply-To: <66C55C26FA491C42A9C9BB62A376DAFF015ED66A@E03MVB1-UKBR.domain1.systemhost.net> References: <66C55C26FA491C42A9C9BB62A376DAFF015ED66A@E03MVB1-UKBR.domain1.systemhost.net> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: Lars Eggert Subject: Re: [PCN] traffic matrix scenario Date: Wed, 31 Oct 2007 13:48:34 +0200 To: "ext ben.strulo@bt.com" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 31 Oct 2007 11:48:37.0651 (UTC) FILETIME=[F958EE30:01C81BB3] X-Nokia-AV: Clean 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 List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2032529576==" Errors-To: pcn-bounces@ietf.org --===============2032529576== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-47-775749745; protocol="application/pkcs7-signature" --Apple-Mail-47-775749745 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, On 2007-10-31, at 12:37, ext ben.strulo@bt.com wrote: > We cannot really give any measure of likelihood. In this deployment > scenario, at least, we design our network so PCN almost never rejects > calls unless the traffic matrix is highly anomalous. Such > anomalies are > inherently unpredictable. For example, a scenario we sometimes > consider > is an event which simultaneously destroys an exchange building and > causes a surge of traffic to and from the affected exchange region > consisting of emergency traffic mixed with concerned relatives calling > up to see what has happened. We cannot tell you how likely this > scenario is. But it is essential to us that PCN operates correctly in > this scenario, regardless of the scenario's precise likelihood. my definition of "operates correctly" includes the possibility of flow termination. I see flow termination as the appropriate measure if the domain gets into a state of sudden, unanticipated overload. I'd like to check if we are in agreement on this, because it is important for understanding the rest of your email (which for this reason I won't comment on yet). If we aren't in agreement, then I wonder under what circumstances you'd consider flow termination to be appropriate? Lars > So, what do we need to do to ensure that PCN does operate correctly in > the presence of extreme anomalous events? > We have a few parameters to play with. One is the margin between > pre-congestion and actual congestion. Another is provided by a cap on > the rate of admitting new flows. > > What the statistics we gave before imply is that this rate must be > quite > tightly capped, at least in the case of ingress-egress aggregates with > no flows, because the size of the pulse of flows we admit before we > get > good feedback could be being multiplied across many other > ingresses, and > together this chunk of admissions must be reliably limited to below > our > safety margin. If the rate of admission is being capped on a per > ingress basis, then the multiplication factor cannot reliably be > assumed > to be much smaller than the total number of ingresses, 100 in our > case. > If the rate of admission is being capped on a per aggregate basis then > our traffic matrix information suggests that we could have a situation > where many aggregates (a few thousand) are all ramping up into the > same > bottleneck. So the multiplication factor needs to be of that order. > > We can do the sums: given the safety margin, the time lag before > feedback becomes reliable, and the multiplication factor we can > directly > compute the maximum rate of admission per ingress and per aggregate. > Alternatively, given a desirable minimum size for this maximum rate of > admission we can compute the needed safety margin. > > What should we take to be the time lag before the feedback becomes > reliable? One component is the amount of time between admission > control > decision and data actually reaching the ingress. Can we assume > this to > be reliably bounded? The other components are then propagation and > queueing delay, alongside the time needed for the bottleneck queues to > grow and the congestion estimates to grow. Do we have good estimates > for these times? > > Ben Strulo --Apple-Mail-47-775749745 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzEwMzExMTQ4MzRaMCMGCSqGSIb3DQEJBDEWBBRE/Zx3Zp0HmleX 4kujWRqKfCx90zCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEA0AQGQ+So5wn3BBXwyxBVSe9ud+rcKpKhbz/4CJLOu71/sKLi5DG6 9OC7LFkKyBiCNkFBhlPq7TewAbi3UThUYVcU9cDcEmGcna6czXXvW0QwTvE3Bw0RICGKBXEjuYvj YJgR42AVPg0if7IWsrN3dn0PzKQUbHeViAM1SQjg9ww55Bq4yONJFP90rtWENbyrIXYX9uwgvoUw J52liQdL1kvW1G35omZUyC0m+uiq1iSIjPG/DpbQYCx1FN8srKB5Shqk81v3gd2aFLdrBIEsKDHM cNfozORR029i2RzfnKtxuT9pSk2mm2C4q5DaOswlPRtLxQBSEOelT7OMtmCihQAAAAAAAA== --Apple-Mail-47-775749745-- --===============2032529576== 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 --===============2032529576==-- From pcn-bounces@ietf.org Wed Oct 31 09:52:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InDz1-0000ra-Tm; Wed, 31 Oct 2007 09:51:47 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1InDyz-0000p1-Qc for pcn-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 09:51:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InDyy-0000oo-KU for pcn@ietf.org; Wed, 31 Oct 2007 09:51:44 -0400 Received: from smtp3.smtp.bt.com ([217.32.164.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InDyy-0005eu-3B for pcn@ietf.org; Wed, 31 Oct 2007 09:51:44 -0400 Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 13:51:43 +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] traffic matrix scenario Date: Wed, 31 Oct 2007 13:51:42 -0000 Message-ID: <66C55C26FA491C42A9C9BB62A376DAFF01631876@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] traffic matrix scenario Thread-Index: AcgbtAMUJBRNv0aKQaWXBINY+6Vq1wAD2ZMg From: To: X-OriginalArrivalTime: 31 Oct 2007 13:51:43.0323 (UTC) FILETIME=[2B8D0AB0:01C81BC5] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi Lars > my definition of "operates correctly" includes the=20 > possibility of flow termination. I see flow termination as=20 > the appropriate measure if the domain gets into a state of=20 > sudden, unanticipated overload. Broadly speaking I think our objective is that flow termination should only be necessary in the case of an unexpected decrease in core capacity. We generally do not expect an Admission Control system to admit calls and then later terminate them in the absence of internal network problems such as link failure. My scenario mentioned the failure of an exchange really only as an example of the sort of extreme scenarios we consider. The real examples I had in mind were simply flash crowds: widespread and unexpected increases in call request rates with an unusual (e.g. regionally focussed) traffic matrix. The sort of scenario that might be particularly testing for this particular probing issue, would be an initial anomalous traffic pattern consisting of very heavy traffic on a few aggregates causing pre-congestion on just a few links, followed by a subsequent widespread increase in demand which also focuses on those links. It is easy to construct reasonable (though not necessarily probable) sequences of external events that could cause this sort of traffic pattern: for example, news reporting initially being local and progressing to national coverage. We would expect an Admission Control system to do a good job of rejecting requests in this scenario. Though this is not completely cut and dried: it's possible a very small amount of flow termination might be acceptable. =20 > If we aren't in agreement, then I wonder under what=20 > circumstances you'd consider flow termination to be appropriate? As I say, only really when there is a sudden and significant decrease in core capacity. Even then, we would normally expect to be provisioned to deal with all but the most serious failures. Ben Strulo _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Oct 31 12:11:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InGAJ-0004w9-UM; Wed, 31 Oct 2007 12:11:35 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1InGAJ-0004w3-7H for pcn-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 12:11:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InGAI-0004vv-TA for pcn@ietf.org; Wed, 31 Oct 2007 12:11:34 -0400 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InGAC-0005c5-9m for pcn@ietf.org; Wed, 31 Oct 2007 12:11:34 -0400 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 16:11:22 +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] traffic matrix scenario Date: Wed, 31 Oct 2007 16:11:21 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B342B7@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] traffic matrix scenario Thread-Index: AcgbtGhiH8Lb5KmRRbmIIdPw1S0iXwAI3VTQ From: To: , X-OriginalArrivalTime: 31 Oct 2007 16:11:22.0854 (UTC) FILETIME=[AE240060:01C81BD8] X-Spam-Score: -1.0 (-) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Lars I agree flow termination may be ok if sudden, unanticipated overload. But then it would be good if flows weren't admitted that would go over the overloaded link(s) - even if new flow is on an ingress-egress-aggregate that currently has no traffic (and therefore can't tell that flow termination is happening). Sorry, I've jumped beyond the scope of your comment... Phil/=20 > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@nokia.com] > Sent: 31 October 2007 11:49 > To: Strulo,B,Ben,CXR9 R > Cc: pcn@ietf.org > Subject: Re: [PCN] traffic matrix scenario >=20 > Hi, >=20 > On 2007-10-31, at 12:37, ext ben.strulo@bt.com wrote: > > We cannot really give any measure of likelihood. In this deployment > > scenario, at least, we design our network so PCN almost never rejects > > calls unless the traffic matrix is highly anomalous. Such > > anomalies are > > inherently unpredictable. For example, a scenario we sometimes > > consider > > is an event which simultaneously destroys an exchange building and > > causes a surge of traffic to and from the affected exchange region > > consisting of emergency traffic mixed with concerned relatives calling > > up to see what has happened. We cannot tell you how likely this > > scenario is. But it is essential to us that PCN operates correctly in > > this scenario, regardless of the scenario's precise likelihood. >=20 > my definition of "operates correctly" includes the possibility of > flow termination. I see flow termination as the appropriate measure > if the domain gets into a state of sudden, unanticipated overload. >=20 > I'd like to check if we are in agreement on this, because it is > important for understanding the rest of your email (which for this > reason I won't comment on yet). >=20 > If we aren't in agreement, then I wonder under what circumstances > you'd consider flow termination to be appropriate? >=20 > Lars >=20 > > So, what do we need to do to ensure that PCN does operate correctly in > > the presence of extreme anomalous events? > > We have a few parameters to play with. One is the margin between > > pre-congestion and actual congestion. Another is provided by a cap on > > the rate of admitting new flows. > > > > What the statistics we gave before imply is that this rate must be > > quite > > tightly capped, at least in the case of ingress-egress aggregates with > > no flows, because the size of the pulse of flows we admit before we > > get > > good feedback could be being multiplied across many other > > ingresses, and > > together this chunk of admissions must be reliably limited to below > > our > > safety margin. If the rate of admission is being capped on a per > > ingress basis, then the multiplication factor cannot reliably be > > assumed > > to be much smaller than the total number of ingresses, 100 in our > > case. > > If the rate of admission is being capped on a per aggregate basis then > > our traffic matrix information suggests that we could have a situation > > where many aggregates (a few thousand) are all ramping up into the > > same > > bottleneck. So the multiplication factor needs to be of that order. > > > > We can do the sums: given the safety margin, the time lag before > > feedback becomes reliable, and the multiplication factor we can > > directly > > compute the maximum rate of admission per ingress and per aggregate. > > Alternatively, given a desirable minimum size for this maximum rate of > > admission we can compute the needed safety margin. > > > > What should we take to be the time lag before the feedback becomes > > reliable? One component is the amount of time between admission > > control > > decision and data actually reaching the ingress. Can we assume > > this to > > be reliably bounded? The other components are then propagation and > > queueing delay, alongside the time needed for the bottleneck queues to > > grow and the congestion estimates to grow. Do we have good estimates > > for these times? > > > > Ben Strulo _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn
-----Original Message-----
From: = philip.eardley@bt.com=20 [mailto:philip.eardley@bt.com]
Sent: Wednesday, October 24, = 2007=20 9:07 PM
To: Geib, Rüdiger
Cc:=20 pcn@ietf.org
Subject: RE: [PCN] PCN &=20 tunnelling

Ruediger,

 

Yes, it is = a more=20 general problem. I’ve been trying to read 2983 [diffserv & = tunnels] and=20 3270 [mpls & diffserv – similar kinds of = issues]

 

2983 has 2 = conceptual=20 models, Uniform & Pipe:

- Uniform: = tunnel is=20 an artefact on the e2e path from a traffic conditioning viewpoint; pkt = effectively has one DS field that’s used for traffic = conditioning. Copy DSCP=20 value to the outer header at encaps and copy outer header’s dscp = value to=20 inner IP header at decaps.

- Pipe: IP = tunnel=20 hides the nodes so they don’t really participate in traffic = conditioning.=20 Tunnel egress ignores the outer header’s dscp & uses the = inner header’s=20 DSCP (or rather the traffic conditioning info it conveys – to = cover the case=20 where the same meaning is encoded by different values of dscp). Tunnel = links=20 DS domains at end points into a diffserv region = (‘virtually’ contiguous).=20

 

When it = comes to PCN=20 & tunnels, something analogous to the Uniform model seems more = appropriate=20 to me – ie the pkt effectively has one field for PCN-marking = that’s used for=20 PCN-based adm ctrl (& termination); the operation is at decaps, if = the=20 outer header’s PCN-marking is more severe than the inner IP = header’s, then=20 copy it to the inner IP header.

At least I = think the=20 Uniform model is best for the normal (?) case where the tunnel is = within the=20 PCN-domain – because we want all nodes in the PCN-domain to be = able=20 potentially to PCN-mark & hence contribute to the adm ctrl = decisions. If=20 the tunnel is partly within a PCN-domain and partly outside I think = the=20 uniform model is still the right one (not too sure – there are = lots of things=20 complicating it, some of which mentioned in first email below, but I = think the=20 conceptual model should still be the same].

 

Ruediger: = question=20 about what you call ‘downpropagation’, I assume this is = the copying operation=20 I refer to in the Uniform model. I agree with you for PCN marking = [text is=20 already in the archit draft on these lines]. However, you also mention = downpropagation of DSCP which I don’t think is correct. =

 

Ruediger, = you mention=20 where the DSCP values have different meanings at the tunnel ingress = &=20 egress (tunnel crosses a diffserv domain boundary). Yes, I believe = this is a=20 general diffserv issue and is covered by 2475.

 

phil

 

-----Original=20 Message-----
From: = Geib,=20 Ruediger [mailto:Ruediger.Geib@t-systems.com]
Sent: 24=20 October 2007 12:10
To: Eardley,PL,Philip,CXR9 = R
Cc: pcn@ietf.org
Subject: RE: [PCN] PCN &=20 tunnelling

 

Phil,

 

I guess = this is a=20 general DiffServ issue too. In case [2] you assume the same DSCP to be = used by=20 the tunnel end point PCN domain as at the tunnel entry. This = assumption=20 may not hold, if the set DSCP is used for another service class = or unused=20 at the end point.

 

I had a = brief glance=20 on RFC2983, "Differentiated Services and Tunnels". Downpropagation of = outer IP=20 header DSCP/PCN settings may be a fairly good=20 recommendation.

 

Regards,

 

Rudiger

-----Original=20 Message-----
From:=20 philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: Wednesday, October 24, = 2007 12:24=20 PM
To:=20 pcn@ietf.org
Subject: [PCN]=20 PCN & tunnelling

Hi,

 

I was chatting with Bob about section 5.8=20 tunnelling. We’ve realised there’s the following nasty = case which we hadn’t=20 thought about. The scenario is when a tunnel starts inside a = PCN-domain and=20 finishes outside it.

 

First we follow what happens when the = current text=20 is followed. Imagine that the pkt is PCN-marked by some PCN-node = before the=20 tunnel start node. On encapsulation the PCN-mark is copied onto the = outer=20 header. Hence the PCN-egress-node ‘sees’ the PCN-mark as = normal – this is=20 ok. The PCN-egress-node clears the marking in the (outer) header and = forwards the pkt into the next domain. The pkt is decapsulated at = the tunnel=20 end point. But the decapsulated pkt is already PCN-marked. Potential = problems: [1] if it’s decapsulated in a non-PCN-domain, then = the pkt may=20 confuse nodes in this domain [depending on what encoding is used for = a=20 PCN-mark] ; [2] if it’s decapsulated in a PCN-domain, then the = pkt is=20 PCN-marked [which might lead this PCN-domain to terminate or block a = flow=20 unnecessarily].

 

The problem arises because the = PCN-egress-node=20 clears PCN-marking on the outer header but not on the inner header. = (This is=20 a new problem compared with ECN & tunnelling.) =

 

Possible solution: if the pkt is = PCN-marked, then=20 the tunnel start node checks whether the tunnel egress is inside or = outside=20 the PCN-domain - if it’s outside, then it clears the = PCN-marking on the=20 inner header (effectively it does this on behalf of the = PCN-egress-node).=20 (Also, the PCN-mark is copied onto the outer header, as the current = text=20 says.)

 

Thoughts?

 

Thanks,

Phil/=20