Subject: [PCN] I-D Action:draft-ietf-pcn-signaling-requirements-03.txt

From: [email-masked]
Date: Tue, 05 Apr 2011 05:15:01 -0700

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           : Requirements for Signaling of (Pre-) Congestion Information in a DiffServ Domain
	Author(s)       : G. Karagiannis, et al.
	Filename        : draft-ietf-pcn-signaling-requirements-03.txt
	Pages           : 7
	Date            : 2011-04-05

Precongestion notification (PCN) is a means for protecting quality of
service for inelastic traffic admitted to a Diffserv domain. The 
overall PCN architecture is described in RFC 5559. This memo 
describes the requirements for the signaling applied within the PCN 
domain: (1) PCN-feedback-information is carried from the PCN-egress-
node to the decision point;(2) the decision point may ask the PCN-
ingress-node to measure, and report back, the rate of PCN-traffic 
between this pair of PCN-boundary-nodes. The decision point may be 
either collocated with the PCN-ingress-node or a centralized node (in 
the latter case, (2) is not required). The signaling requirements 
pertain in particular to two edge behaviours, "controlled load (CL)" 
and "single marking (SM)" [draft-ietf-pcn-cl-edge-behaviour-08], 
[draft-ietf-pcn-sm-edge-behaviour-05].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pcn-signaling-requirements-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Michael Menth <[email-masked]>
Date: Tue, 05 Apr 2011 23:45:35 +0200

Hi Georgios, hi all,

I quickly went over the draft and fixed some nits. I think it is in good 
shape now. Georgios, please take care of my minor corrections for the 
next version of the doc!

Best wishes,

     Michael

Am 05.04.2011 14:15, schrieb [email-masked]:
> _______________________________________________
> PCN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcn

-- 
Prof. Dr. habil. Michael Menth
University of Tuebingen
Faculty of Science
Department of Computer Science
Chair of Communication Networks
Sand 13, 72076 Tuebingen, Germany
phone: (+49)-7071/29-70505
fax: (+49)-7071/29-5220
mailto:[email-masked]
http://www-kn.informatik.uni-tuebingen.de

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 6 Apr 2011 10:31:30 +0200

Hi Michael
 
Thanks for the comments!
 
I agree with all comments, except the following one:

Issue  2: Regarding flow identifiers, the following is not needed: 
   o  IP address of PCN-ingress-node; 
  o  IP address of PCN-egress-node 

First of all please note that these are needed in the situation that the
flow ID identifies an aggregated flow. In this case  the "IP address of
PCN-ingress-node" and the "IP address of PCN-egress-node" are, among other
information, required.
Moreover please note that before the list with bullets the following
sentence is used:
"In pure IP networks, the identifier may consist of a subset of the
following information:". 
This means that in some situations you can use a subset of this list to
identify an individual flow and in other cases you can use a subset of the
same list to identify an aggregated flow.

Secondly I thought that during the IETF meeting we discussed the same issue
and there was an agreement to have this information in the flow identifier.
!?

Best regards,
Georgios

________________________________

	From: [email-masked] [mailto:[email-masked]] On Behalf
Of Michael Menth
	Sent: dinsdag 5 april 2011 23:46
	To: [email-masked]
	Subject: Re: [PCN] I-D
Action:draft-ietf-pcn-signaling-requirements-03.txt

	Hi Georgios, hi all,
	
	I quickly went over the draft and fixed some nits. I think it is in
good shape now. Georgios, please take care of my minor corrections for the
next version of the doc!
	
	Best wishes,
	
	    Michael

		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           : Requirements for Signaling of
(Pre-) Congestion Information in a DiffServ Domain
			Author(s)       : G. Karagiannis, et al.
			Filename        :
draft-ietf-pcn-signaling-requirements-03.txt
			Pages           : 7
			Date            : 2011-04-05
		
		Precongestion notification (PCN) is a means for protecting
quality of
		service for inelastic traffic admitted to a Diffserv domain.
The 
		overall PCN architecture is described in RFC 5559. This memo

		describes the requirements for the signaling applied within
the PCN 
		domain: (1) PCN-feedback-information is carried from the
PCN-egress-
		node to the decision point;(2) the decision point may ask
the PCN-
		ingress-node to measure, and report back, the rate of
PCN-traffic 
		between this pair of PCN-boundary-nodes. The decision point
may be 
		either collocated with the PCN-ingress-node or a centralized
node (in 
		the latter case, (2) is not required). The signaling
requirements 
		pertain in particular to two edge behaviours, "controlled
load (CL)" 
		and "single marking (SM)"
[draft-ietf-pcn-cl-edge-behaviour-08], 
		[draft-ietf-pcn-sm-edge-behaviour-05].

http://www.ietf.org/internet-drafts/draft-ietf-pcn-signaling-requirements-03
.txt

		Below is the data which will enable a MIME compliant mail
reader
		implementation to automatically retrieve the ASCII version
of the
		Internet-Draft.

---

From: Michael Menth <[email-masked]>
Date: Wed, 06 Apr 2011 11:03:18 +0200

Hi Georgios,

in the meeting (and in fact days before!) we agreed that we determine 
ingress-egress-aggregates by the IP addresses of the PCN-ingress-node 
and PCN-egress-node.

The PCN-egress-node gains the information about the PCN-ingress-node 
somehow and sends a report to the PCN-ingress-node. Therefore, the 
information about the PCN-ingress-node and PCN-egress-node is already 
there. Furthermore, the PCN-ingress-node and PCN-egress-node do not 
further characterize any aggregate flows at least to my understanding. 
Therefore, I think that adding to the description of flows their 
PCN-ingress-node and PCN-egress-node is 1) redundant and 2) not helpful 
and, therefore, rather confuses readers.

Best wishes,

     Michael

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 6 Apr 2011 11:55:53 +0200

Hi Michael

This issue is about flow ID, and is not about reporting addresses. 
Regarding identification of aggregated flows, please read:

http://www.rfc-editor.org/rfc/rfc3175.txt

Since IEAs are used in PCN, this will mean that the signaling protocol used
to carry PCN information from PCN-egress-node to decision point 
should be able to identify IEAs (ingress-egress-aggregates).

In PCN an aggregated flow that is representing an IEA ( 
should be at least identified by the combination of:

  o  DSCP field

Moreover, it should be able to identify which individual flows are belonging
and using such an IEA. 

In other words this information is not redundant, but it is required.

Best regards,
Georgios

> -----Original Message-----
> From: Michael Menth [mailto:[email-masked]] 
> Sent: woensdag 6 april 2011 11:03
> To: Georgios Karagiannis
> Cc: [email-masked]
> Subject: Re: [PCN] I-D 
> in the meeting (and in fact days before!) we agreed that we 
> determine ingress-egress-aggregates by the IP addresses of 
> the PCN-ingress-node and PCN-egress-node.
> 
> The PCN-egress-node gains the information about the 
> PCN-ingress-node somehow and sends a report to the 
> PCN-ingress-node. Therefore, the information about the 
> PCN-ingress-node and PCN-egress-node is already there. 
> Furthermore, the PCN-ingress-node and PCN-egress-node do not 
> Therefore, I think that adding to the description of flows 
> their PCN-ingress-node and PCN-egress-node is 1) redundant 
> and 2) not helpful and, therefore, rather confuses readers.
> 
> Best wishes,
> 
>      Michael
> 
> > First of all please note that these are needed in the 
> situation that 
> > the flow ID identifies an aggregated flow. In this case  the "IP 
> > address of PCN-ingress-node" and the "IP address of 
> PCN-egress-node" 
> > are, among other information, required.
> > This means that in some situations you can use a subset of 
> this list 
> > to identify an individual flow and in other cases you can 
> use a subset 
> > of the same list to identify an aggregated flow.
> >
> >
> > Secondly I thought that during the IETF meeting we 
> discussed the same 
> > issue and there was an agreement to have this information 
> in the flow identifier.
> > !?
> >
> >
> > Best regards,
> > Georgios
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > 	From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> > Michael Menth
> > good shape now. Georgios, please take care of my minor 
> corrections for 
> > the next version of the doc!
> > 	
> > 	Best wishes,
> > 	
> > 	    Michael
> > 	
> > 		A New Internet-Draft is available from the 
> on-line Internet-Drafts 
> > directories.
> > 		Precongestion notification (PCN) is a means for 
> protecting quality 
> > of
> > 		either collocated with the PCN-ingress-node or 
> a centralized node 
> > (in

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 7 Apr 2011 11:19:48 +0200

Hi all

Looking into the description of the edge behaviour drafts and what we
currently have in the 03 version of the signaling requirements draft, I see
that some information associated with the information that a signaling
protocol should carry is missing. In particular, we are not specifying what
is the maximum value of the rates that a signaling protocol should be able
to carry. This is important in order to specify what will be maximum length
of the field that carries such a maximum rate.

In particular we need to have these maximum values for the following rates:

   o the rate of not-marked PCN-traffic (NM-rate) in octets/second,
   o rate of PCN-marked traffic in octets/second,
   o the rate of threshold-marked PCN traffic (ThM-rate) in 
     octets/second,
   o rate of excess-traffic-marked traffic (ETM-rate) in octets/second,

We could use a field of 32 bits long => Maximum rate value = 2^32 =
4294967296 octets/s)

Question 1: Is this maximum rate value acceptable? 

Question 2: Is it okay to include this maximum rate value in the signaling
requirements draft, 
or should we do this in the edge behaviour drafts?

Best regards, 
Georgios

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: dinsdag 5 april 2011 14:15
> To: [email-masked]
> Cc: [email-masked]
> Subject: [PCN] I-D Action:draft-ietf-pcn-signaling-requirements-03.txt
> 
> 	Title           : Requirements for Signaling of (Pre-) 
> Congestion Information in a DiffServ Domain
> quality of service for inelastic traffic admitted to a 
> Diffserv domain. The overall PCN architecture is described in 
> RFC 5559. This memo describes the requirements for the 
> signaling applied within the PCN
> PCN-egress- node to the decision point;(2) the decision point 
> may ask the PCN- ingress-node to measure, and report back, 
> the rate of PCN-traffic between this pair of 
> PCN-boundary-nodes. The decision point may be either 
> collocated with the PCN-ingress-node or a centralized node 
> (in the latter case, (2) is not required). The signaling 
> requirements pertain in particular to two edge behaviours, 
> "controlled load (CL)" 
> reader implementation to automatically retrieve the ASCII 
> version of the Internet-Draft.
>

---

From: <[email-masked]>
Date: Thu, 7 Apr 2011 10:33:45 +0100

I dont think this is needed in either signalling reqts or edge behaviour docs. I think this would be up to the actual signalling protocol to define, or perhaps the configuration in a particular PCN-domain.
Note also that defining a field length doesn't define the max value, as this depends on the encoding [for instance, 1 byte might be an exponent]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Georgios Karagiannis
Sent: 07 April 2011 10:20
To: [email-masked]
Subject: [PCN] Perhaps some additions required for draft-ietf-pcn-signaling-requirements-03.txt

Hi all

Best regards, 
Georgios

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 7 Apr 2011 11:55:44 +0200

Hi Phil

You are right about the encoding. Therefore, we might also need to define
the way of how this value is encoded. 

In RFC 2210 all the rate values are encoded using: 32-bit IEEE floating
point number.

I am not sure if it is good lo leave this decision to other desigbn teams
than the PCN WG.

The values of these rates are affecting the accuracy of the provided PCN
solutions, 
in particular when they get another value than they should.

Best regards,
Georgios

> From: [email-masked] [mailto:[email-masked]] 
> Sent: donderdag 7 april 2011 11:34
> To: [email-masked]; [email-masked]
> Subject: RE: [PCN] Perhaps some additions required 
> fordraft-ietf-pcn-signaling-requirements-03.txt
> 
> I dont think this is needed in either signalling reqts or 
> edge behaviour docs. I think this would be up to the actual 
> signalling protocol to define, or perhaps the configuration 
> in a particular PCN-domain.
> Note also that defining a field length doesn't define the max 
> value, as this depends on the encoding [for instance, 1 byte 
> might be an exponent]
> 
> Behalf Of Georgios Karagiannis
> Subject: [PCN] Perhaps some additions required for 
> Looking into the description of the edge behaviour drafts and 
> what we currently have in the 03 version of the signaling 
> requirements draft, I see that some information associated 
> with the information that a signaling protocol should carry 
> is missing. In particular, we are not specifying what is the 
> maximum value of the rates that a signaling protocol should 
> be able to carry. This is important in order to specify what 
> will be maximum length of the field that carries such a maximum rate.
> 
> Question 2: Is it okay to include this maximum rate value in 
> the signaling requirements draft, or should we do this in the 
> edge behaviour drafts?
> 
> Best regards,
> Georgios
> 
> 
> 
> > Subject: [PCN] I-D

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 13 Apr 2011 18:28:07 +0200

Hi all

>From the WGLC discussions regarding draft-ietf-pcn-signaling-requirements-03
I identified two open issues:

This email contains the first open issue:
 
Issue_1: It is proposed that draft-ietf-pcn-signaling-requirements should
recommend which maximum rate value should be carried by a signaling
protocol.

This will mean that the PCN WG will recommend to the signaling protocol
designers to use a container/field that is able to carry this maximum rate
value (in octets/s).

Question: Do you agree/disagree with the fact that
draft-ietf-pcn-signaling-requirements should recommend which maximum rate
value should be carried by a signaling protocol?

Best regards,
Georgios

> Sent: donderdag 7 april 2011 11:56
> To: [email-masked]; [email-masked]
> Subject: Re: [PCN] Perhaps some additions 
> requiredfordraft-ietf-pcn-signaling-requirements-03.txt
> 
> Hi Phil
> 
> You are right about the encoding. Therefore, we might also 
> need to define the way of how this value is encoded. 
> 
> In RFC 2210 all the rate values are encoded using: 32-bit 
> IEEE floating point number.
> 
> I am not sure if it is good lo leave this decision to other 
> desigbn teams than the PCN WG.
> 
> The values of these rates are affecting the accuracy of the 
> provided PCN solutions, in particular when they get another 
> value than they should.
> 
> Best regards,
> Georgios
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> > I dont think this is needed in either signalling reqts or edge 
> > behaviour docs. I think this would be up to the actual signalling 
> > protocol to define, or perhaps the configuration in a particular 
> > PCN-domain.
> > Note also that defining a field length doesn't define the 
> max value, 
> > as this depends on the encoding [for instance, 1 byte might be an 
> > exponent]
> > 
> > currently have in the 03 version of the signaling 
> requirements draft, 
> > I see that some information associated with the information that a 
> > signaling protocol should carry is missing. In particular, 
> we are not 
> > specifying what is the maximum value of the rates that a signaling 
> > protocol should be able to carry. This is important in order to 
> > specify what will be maximum length of the field that 
> carries such a 
> > maximum rate.
> > 
> > In particular we need to have these maximum values for the 
> following 
> > rates:
> > 
> > Question 2: Is it okay to include this maximum rate value in the 
> > signaling requirements draft, or should we do this in the edge 
> > behaviour drafts?
> > 
> > Best regards,
> > Georgios
> > 
> > 
> > 
> > > Of [email-masked]
> > > of service for inelastic traffic admitted to a Diffserv 
> domain. The 
> > > PCN-egress- node to the decision point;(2) the decision point may 
> > > ask the PCN- ingress-node to measure, and report back, 
> the rate of 
> > > PCN-traffic between this pair of PCN-boundary-nodes. The decision 
> > > point may be either collocated with the PCN-ingress-node or a 
> > > centralized node (in the latter case, (2) is not required). The 
> > > signaling requirements pertain in particular to two edge 
> behaviours, 
> > > "controlled load (CL)"

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 13 Apr 2011 18:31:39 +0200

Hi all

This email contains the second open issue:
 
Issue_2: IP addresses of PCN-edge-nodes should be removed from flow ID
subset list

draft-ietf-pcn-signaling-requirements specifies that in pure IP networks,
the identifier may consist of a subset of the following information:

   o  source IP address;

   o  destination IP address;

   o  protocol identifier and higher layer (port) addressing;

   o  flow label (typical for IPv6);

   o  SPI field for IPsec encapsulated data; 

   o  DSCP/TOS field;

There was a request to remove the following two bullets from the above list:

The given reason was: "This does certainly not belong to the flow
identifier."

In my opinion these IP addresses of the PCN-edge-nodes are needed for cases
that the flow ID identifies an aggregated flow. 

Since IEAs (Ingress Egress Aggregates) are used in PCN, this will mean that
the signaling protocol used to carry PCN information from PCN-egress-node to
decision point should be able to identify IEAs.

In PCN, an aggregated flow that is representing an IEA, should be at least
identified by the combination of:

The currently given flow ID subset list in
draft-ietf-pcn-signaling-requirements-03 is able to cover both types of flow
IDs (for IEAs and for individual flows).

Question: Do you agree/disagree on removing the IP addresses of the
PCN-ingress-node and PCN-egress-node from the flow ID subset list?

Best regards,
Georgios

> Sent: woensdag 6 april 2011 11:56
> To: 'Michael Menth'
> Cc: [email-masked]
> Subject: Re: [PCN] I-D 
> Since IEAs are used in PCN, this will mean that the signaling 
> protocol used to carry PCN information from PCN-egress-node 
> to decision point should be able to identify IEAs 
> (ingress-egress-aggregates).
> 
> Moreover, it should be able to identify which individual 
> flows are belonging and using such an IEA. 
> 
> determine 
> PCN-ingress-node 
> > there.
> > Furthermore, the PCN-ingress-node and PCN-egress-node do 
> not further 
> > characterize any aggregate flows at least to my understanding.
> > PCN-ingress-node and PCN-egress-node is 1) redundant and 2) not 
> > helpful and, therefore, rather confuses readers.
> > 
> > Best wishes,
> > 
> >      Michael
> >

---

From: Michael Menth <[email-masked]>
Date: Wed, 13 Apr 2011 22:02:47 +0200

Hi Georgios,

I disagree with your proposal. The egress node signals to the decision 
point the IEA anyway from which traffic should be terminated. The IDs of 
marked flows are needed only in case of multipath routing when the 
information about the IEA is not sufficient to choose flows for 
termination. So the argument against the inclusion is twofold:
1) The decision point has already the information about the IEA
2) The information about the IEA is not helpful to denote flows for 
termination when IDs of marked flows are requested.

If you can describe a sensible concrete use case where the inclusion 
still helps, then I may change my mind.

Best wishes,

     Michael

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 14 Apr 2011 06:42:46 +0000

Hi Michael

I think that my arguments were clear:

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

>>In my opinion these IP addresses of the PCN-edge-nodes are needed for cases that the flow ID identifies an aggregated flow.
>>
>> Since IEAs (Ingress Egress Aggregates) are used in PCN, this will mean that the signaling protocol used to carry PCN information from PCN-egress-node to decision point should be able to identify IEAs.
>>
>> draft-ietf-pcn-signaling-requirements-03 is able to cover both types of flow IDs (for IEAs and for individual flows).

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

In addition to the above, the signaling requirements draft gives
recommendations to designers of signaling protocols. In this particular
case, the recommendation that the signaling requirements draft gives is
that if a signaling protocol needs to identify flow IDs in pure IP
networks, then the signaling protocol designers could pick information
(a subset) from the flow ID list that is given in the signaling
requirements draft.

As example:

>>     o  IP address of PCN-egress-node

More discussion is needed on the PCN list regarding this issue, and in
particular by people that have experience on designing signaling
protocols.

Best regards,
Georgios

pure IP networks,

---

From: <[email-masked]>
Date: Thu, 14 Apr 2011 11:15:37 +0100

<< In my opinion these IP addresses of the PCN-edge-nodes are needed for cases
that the flow ID identifies an aggregated flow.>>

what you say is true. 
However, the draft says:
<< the report MUST contain:
o the identifier of the PCN-ingress-node and the identifier of the
     PCN-egress-node (typically their IP addresses); together they
     specify the ingress-egress-aggregate to which the report refers,>>
ie the information is already there - which is michael's point.
The issue is that in S2.1 we say what the identifier may consist of, and imply this is what is in the actual message. 

so can we solve this by replacing:
<<the identifier may consist of a subset of the following information:

   o  source IP address;

   o  DSCP/TOS field;

By

<< the identifier may consist of a subset of the following information:

   o  source IP address;

   o  DSCP/TOS field;

   Note, where a PCN-flow consists of a collection of microflows, then the PCN-flow is identified by the PCN-ingress-node's and PCN-egress-node's identifiers (typically their IP addresses), which are already part of the report. >>

I also suggest replacing "flow" by "PCN-flow" in:
<< For both CL and SM edge behaviours, the report MAY also contain:
   o a set of flow identifiers (see Section 2.1).>>
<< 2.1 Specification of Flow Identifiers>>
<<The representation of a flow identifier>>
<< Examples of such flow identifier representations>>

In the first of these instances, you could safely add a reference to rfc5559, where PCN-flow is a defined term. 

Does this work?
Phil

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Georgios Karagiannis
Sent: 13 April 2011 17:32
To: [email-masked]
Subject: [PCN] Open Issue 2: should IP addresses of PCN-edge-nodes be removed from flow ID subset list?

 Hi all

 

   o  source IP address;

   o  DSCP/TOS field;

Best regards,
Georgios

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 14 Apr 2011 12:21:23 +0200

Hi Phil

Your proposals seem fine for me!

Best regards,
Georgios

> Sent: donderdag 14 april 2011 12:16
> Subject: RE: [PCN] Open Issue 2: should IP addresses of 
> PCN-edge-nodes beremoved from flow ID subset list?
> 
> << In my opinion these IP addresses of the PCN-edge-nodes are 
> needed for cases that the flow ID identifies an aggregated flow.>>
> 
> what you say is true. 
> However, the draft says:
>      specify the ingress-egress-aggregate to which the report 
> refers,>> ie the information is already there - which is 
> michael's point.
> The issue is that in S2.1 we say what the identifier may 
> consist of, and imply this is what is in the actual message. 
> 
>    Note, where a PCN-flow consists of a collection of 
> microflows, then the PCN-flow is identified by the 
> PCN-ingress-node's and PCN-egress-node's identifiers 
> (typically their IP addresses), which are already part of the 
> report. >>
> 
>    o a set of flow identifiers (see Section 2.1).>> << 2.1 
> Specification of Flow Identifiers>> <<The representation of a 
> flow identifier>> << Examples of such flow identifier 
> representations>>
> 
> In the first of these instances, you could safely add a 
> reference to rfc5559, where PCN-flow is a defined term. 
> 
> Does this work?
> Phil
> 
> Subject: [PCN] Open Issue 2: should IP addresses of 
> PCN-edge-nodes be removed from flow ID subset list?
> 
> 
>  Hi all
> 
> Issue_2: IP addresses of PCN-edge-nodes should be removed 
> from flow ID subset list
> 
> draft-ietf-pcn-signaling-requirements specifies that in pure 
> IP networks, the identifier may consist of a subset of the 
> following information:
> 
>    o  source IP address;
> 
> 
> The given reason was: "This does certainly not belong to the 
> flow identifier."
> 
> In my opinion these IP addresses of the PCN-edge-nodes are 
> needed for cases that the flow ID identifies an aggregated flow. 
> 
> Since IEAs (Ingress Egress Aggregates) are used in PCN, this 
> will mean that the signaling protocol used to carry PCN 
> information from PCN-egress-node to decision point should be 
> able to identify IEAs.
> 
> In PCN, an aggregated flow that is representing an IEA, 
> draft-ietf-pcn-signaling-requirements-03 is able to cover 
> both types of flow IDs (for IEAs and for individual flows).
> 
> Question: Do you agree/disagree on removing the IP addresses 
> of the PCN-ingress-node and PCN-egress-node from the flow ID 
> subset list?
> 
> 
> 
> Best regards,
> Georgios
> 
> > Since IEAs are used in PCN, this will mean that the 
> signaling protocol 
> > used to carry PCN information from PCN-egress-node to 
> decision point 
> > Moreover, it should be able to identify which individual flows are 
> > belonging and using such an IEA.
> >

---

From: <[email-masked]>
Date: Thu, 14 Apr 2011 11:28:56 +0100

I dont think this belongs in this document. Seems it can be left to the actual signalling protocol and configuration in the actual network it's operating in. Anyway, if we specify a particular maximum we also need to specify format and that requires some work on what ways are currently considered best. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Georgios Karagiannis
Sent: 13 April 2011 17:28
To: [email-masked]
Subject: [PCN] Open Issue 1: should draft-ietf-pcn-signaling-requirements recommend which maximum rate value carried by signaling protocol?

Hi all

 

Best regards,
Georgios

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 14 Apr 2011 12:59:12 +0200

Hi Phil

Agree, but maybe the following sentence could solve the problem!

"The signaling protocol SHOULD be able to carry a rate value that can at
least be fitted in a 32 bit container/field, when using the IEEE floating
point number encoding."

The above is based on the fact that a token bucket rate carried in a RSVP
SENDER_TSPEC Object (see RFC2210), uses also such a container/field.

Best regards,
Georgios

> Sent: donderdag 14 april 2011 12:29
> Subject: RE: [PCN] Open Issue 1: should 
> draft-ietf-pcn-signaling-requirements recommend which maximum 
> rate value carried by signaling protocol?
> 
> I dont think this belongs in this document. Seems it can be 
> left to the actual signalling protocol and configuration in 
> the actual network it's operating in. Anyway, if we specify a 
> particular maximum we also need to specify format and that 
> requires some work on what ways are currently considered best. 
> 
> Subject: [PCN] Open Issue 1: should 
> draft-ietf-pcn-signaling-requirements recommend which maximum 
> rate value carried by signaling protocol?
> 
> 
>  
> Hi all
> 
> Issue_1: It is proposed that 
> draft-ietf-pcn-signaling-requirements should recommend which 
> maximum rate value should be carried by a signaling protocol.
> 
> This will mean that the PCN WG will recommend to the 
> signaling protocol designers to use a container/field that is 
> able to carry this maximum rate value (in octets/s).
> 
> draft-ietf-pcn-signaling-requirements should recommend which 
> maximum rate value should be carried by a signaling protocol?
> 
> Best regards,
> Georgios
> 
> 
> 
> > You are right about the encoding. Therefore, we might also need to 
> > define the way of how this value is encoded.
> > 
> > In RFC 2210 all the rate values are encoded using: 32-bit IEEE 
> > floating point number.
> > 
> > I am not sure if it is good lo leave this decision to other desigbn 
> > teams than the PCN WG.
> > 
> provided 
> > PCN solutions, in particular when they get another value than they 
> > should.
> > 
> > Best regards,
> > Georgios
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >

---

From: <[email-masked]>
Date: Thu, 14 Apr 2011 12:01:18 +0100

Well, if you include your sentence that means you don't agree!

As i said, i don't think this is a good idea. 

-----Original Message-----
From: Georgios Karagiannis [mailto:[email-masked]] 
Sent: 14 April 2011 11:59
To: Eardley,PL,Philip,DES8 R; [email-masked]
Subject: RE: [PCN] Open Issue 1: should draft-ietf-pcn-signaling-requirements recommend which maximum rate value carried by signaling protocol?

Hi Phil

Best regards,
Georgios

---

From: "Toby Moncaster" <[email-masked]>
Date: Thu, 14 Apr 2011 12:27:10 +0100

Phil's proposal sounds good to me too...

Toby

> Sent: 14 April 2011 11:21
> Subject: Re: [PCN] Open Issue 2: should IP addresses of PCN-edge-nodes
> beremoved from flow ID subset list?
> 
> Hi Phil
> 
> > http://www.ietf.org/internet-drafts/draft-ietf-pcn-signaling-
> requireme
> > > > > nts-03
> > > > > .txt
> > > > >

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 14 Apr 2011 13:29:44 +0200

Hi Phil

Okay, my agreement is related to your statement: 

> "Anyway, if we specify a particular 
> maximum we also 
> > need to specify format and that requires some work on what ways are 
> > currently considered best."

The PCN WG specified the PCN solutions, so in my opinion the specification
of this maximum 
should also be considered to be a PCN WG activity.

In my opinion a sentence like the one given below will solve this issue:

"The signaling protocol SHOULD be able to carry a rate value that can at
least be fitted in a 32 bit container/field, when 
using the IEEE floating point number encoding."

Note that the above is based on the fact that a token bucket rate carried in
a RSVP SENDER_TSPEC Object (see RFC2210), uses 
also such a container/field. 

Furthermore, note that by using a SHOULD in the sentence it will mean that
the signaling protocol designers 
could choose something different, considering that this change is
justifiable.

Best regards,
Georgios

> Sent: donderdag 14 april 2011 13:01
> "The signaling protocol SHOULD be able to carry a rate value 
> that can at least be fitted in a 32 bit container/field, when 
> using the IEEE floating point number encoding."
> 
> The above is based on the fact that a token bucket rate 
> carried in a RSVP SENDER_TSPEC Object (see RFC2210), uses 
> also such a container/field.
> 
> Best regards,
> Georgios
> 
> 
> 
> 
> 
> 
> > draft-ietf-pcn-signaling-requirements recommend which maximum rate 
> > value carried by signaling protocol?
> > 
> > I dont think this belongs in this document. Seems it can be left to 
> > the actual signalling protocol and configuration in the 
> actual network 
> > it's operating in. Anyway, if we specify a particular 
> maximum we also 
> > need to specify format and that requires some work on what ways are 
> > currently considered best.
> > 
> > draft-ietf-pcn-signaling-requirements recommend which maximum rate 
> > value carried by signaling protocol?
> > 
> > 
> >  
> > Hi all
> > 
> > draft-ietf-pcn-signaling-requirements should recommend 
> which maximum 
> > rate value should be carried by a signaling protocol.
> > 
> > This will mean that the PCN WG will recommend to the signaling 
> > protocol designers to use a container/field that is able to 
> carry this 
> > maximum rate value (in octets/s).
> > 
> > draft-ietf-pcn-signaling-requirements should recommend 
> which maximum 
> > rate value should be carried by a signaling protocol?
> > 
> > Best regards,
> > Georgios
> > 
> > 
> >

---

From: "Toby Moncaster" <[email-masked]>
Date: Thu, 14 Apr 2011 12:31:06 +0100

There seem to be two competing things - firstly, we need to give some
indication of the scale of number that needs to be signalled (e.g. a short
integer is probably not enough!). BUT we mustn't impose an unnecessary limit
on the maximum since this puts a limit on future growth (just look at IPv4
addressing).

The usual cop-out in such cases is not to recommend anything but to have a
sentence setting out the discussion. Something like

"The rate value carried by the signalling protocol will limit the maximum
rate that PCN can use. If signalling space is tight it might be reasonable
to impose a limit, but any such limit may impose unnecessary constraints in
future"

Toby

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: 14 April 2011 12:01
> Subject: Re: [PCN] Open Issue 1: should draft-ietf-pcn-signaling-
> requirements recommend which maximum rate value carried by signaling
> protocol?
> 
> Subject: RE: [PCN] Open Issue 1: should draft-ietf-pcn-signaling-
> requirements recommend which maximum rate value carried by signaling
> protocol?
> 
> Hi Phil
>

---

From: <[email-masked]>
Date: Thu, 14 Apr 2011 12:31:56 +0100

wfm

-----Original Message-----
From: Toby Moncaster [mailto:[email-masked]] 
Sent: 14 April 2011 12:31
To: Eardley,PL,Philip,DES8 R; [email-masked]; [email-masked]
Subject: RE: [PCN] Open Issue 1: should draft-ietf-pcn-signaling-requirements recommend which maximum rate value carried by signaling protocol?

Toby

---

From: <[email-masked]>
Date: Thu, 14 Apr 2011 12:40:20 +0100

wfm = works for me
Sorry for the abbreviated typing!
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 14 April 2011 12:32
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [PCN] Open Issue 1: should draft-ietf-pcn-signaling-requirements recommend which maximum rate value carried by signaling protocol?

wfm

-----Original Message-----
From: Toby Moncaster [mailto:[email-masked]] 
Sent: 14 April 2011 12:31
To: Eardley,PL,Philip,DES8 R; [email-masked]; [email-masked]
Subject: RE: [PCN] Open Issue 1: should draft-ietf-pcn-signaling-requirements recommend which maximum rate value carried by signaling protocol?

Toby

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 14 Apr 2011 13:46:56 +0200

Hi all

The below sentence satisfies only partially my concerns! However, if there
are no objections then I will use the below sentence in the signaling
requirements draft!

future."

Best regards,
Georgios

> Sent: donderdag 14 april 2011 13:40
> To: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Behalf Of [email-masked]
> Subject: Re: [PCN] Open Issue 1: should 
> There seem to be two competing things - firstly, we need to 
> give some indication of the scale of number that needs to be 
> signalled (e.g. a short integer is probably not enough!). BUT 
> we mustn't impose an unnecessary limit on the maximum since 
> this puts a limit on future growth (just look at IPv4 addressing).
> 
> The usual cop-out in such cases is not to recommend anything 
> but to have a sentence setting out the discussion. Something like
> 
> "The rate value carried by the signalling protocol will limit 
> the maximum rate that PCN can use. If signalling space is 
> tight it might be reasonable to impose a limit, but any such 
> limit may impose unnecessary constraints in future"
> 
> Toby
> 
> Behalf Of 
> > "The signaling protocol SHOULD be able to carry a rate 
> value that can 
> > at least be fitted in a 32 bit container/field, when using the IEEE 
> > floating point number encoding."
> > 
> carried in a 
> > RSVP SENDER_TSPEC Object (see RFC2210), uses also such a 
> > container/field.
> > 
> > Best regards,
> > Georgios
> > 
> > 
> > 
> > 
> > 
> > 
> > > the actual signalling protocol and configuration in the actual 
> > > network it's operating in. Anyway, if we specify a particular 
> > > maximum we also need to specify format and that requires 
> some work 
> > > on what ways are currently considered best.
> > >
> > > Of Georgios Karagiannis
> > > protocol designers to use a container/field that is able to carry 
> > > this maximum rate value (in octets/s).
> > >
> > > > > behaviour docs. I think this would be up to the actual 
> > > > > signalling protocol to define, or perhaps the 
> configuration in a 
> > > > > particular PCN-domain.
> > > > > as this depends on the encoding [for instance, 1 byte 
> might be 
> > > > > an exponent]
> > > > >
> > > > > > centralized node (in the latter case, (2) is not required). 
> > > > > > The signaling requirements pertain in particular to two edge
> > > > behaviours,
> > > > > > "controlled load (CL)"

---

From: Michael Menth <[email-masked]>
Date: Fri, 15 Apr 2011 10:52:07 +0200

Hi Georgios,

Am 14.04.2011 13:46, schrieb Georgios Karagiannis:
> "The rate value carried by

you probably mean: the number format ant the rate units used by

Regards,

     Michael

> the signalling protocol will limit the maximum
>>>>> Georgios Karagiannis
>>>>>> Georgios Karagiannis

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 15 Apr 2011 13:24:32 +0200

Hi Michael

Good point!

The sentence to be added will then become:

"The number format and the rate units used by the signalling protocol will
limit the maximum rate that PCN can use. 
If signalling space is tight it might be reasonable to impose a limit, 
but any such limit may impose unnecessary constraints in future."

Best regards,
Georgios

> Sent: vrijdag 15 april 2011 10:52
> To: Georgios Karagiannis
> Cc: [email-masked]; [email-masked]; [email-masked]
> > The below sentence satisfies only partially my concerns! 
> However, if 
> > there are no objections then I will use the below sentence in the 
> > signaling requirements draft!
> >
> > the signalling protocol will limit the maximum rate that 
> PCN can use. 
> > If signalling space is tight it might be reasonable to 
> impose a limit, 
> > but any such limit may impose unnecessary constraints in future."
> >
> > Best regards,
> > Georgios
> >
> >
> >
> >
> >> indication of the scale of number that needs to be 
> signalled (e.g. a 
> >> short integer is probably not enough!). BUT we mustn't impose an 
> >> unnecessary limit on the maximum since this puts a limit on future 
> >> growth (just look at IPv4 addressing).
> >>
> >> The usual cop-out in such cases is not to recommend 
> anything but to 
> >> have a sentence setting out the discussion. Something like
> >>
> >> "The rate value carried by the signalling protocol will limit the 
> >> maximum rate that PCN can use. If signalling space is 
> tight it might 
> >> be reasonable to impose a limit, but any such limit may impose 
> >> unnecessary constraints in future"
> >>
> >> Toby
> >>