Subject: [PCN] Why is PCN only supporting trunk (ingress-egresss-aggregated) model?

From: "Lars Westberg" <[email-masked]>
Date: Thu, 3 Apr 2008 07:16:05 +0200

Hi, 
From the PCN architecture draft that I have read and from the
discussions that I have followed I see that PCN is currently only
supporting the trunk aggregation model, where ingress-egreess-aggregated
states are used. Thus each ingress and egress will use per each ingress
- egress set one aggregated state.
In am concerned about the scalabillity to large networks. This is due to
the 
N^2 trunk mesh of trunks, where N represents the number of edges in a
network. 
I think it would be good if PCN could support the HOSE model, where no
aggregation states are used to model a bandwidth limit. Therefore, I
would recommend to look into PCN -extention for HOSE type scenario.
comments? 
-lasse 
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: <[email-masked]>
Date: Thu, 3 Apr 2008 08:51:16 +0100

Lasse

To check: the hose model would mean that the admission decision is made
at each ingress node, regardless of what egress the traffic is destined
to. So, a PCN hose model would involve each ingress getting congestion
reports from every egress (for traffic from that ingress) and recording
them as a collected (aggregated) value of pre-congestion. 

As far as I know, no-one has looked at this - I don't think we should
delay current progress by looking at it, since it seems to me a
significant change to the conceptual model. But it looks to me like an
extension that could easily be done with the pcn technology described in
the architecture draft. 

phil

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Lars Westberg
Sent: 03 April 2008 06:16
To: [email-masked]
Subject: [PCN] Why is PCN only supporting trunk
(ingress-egresss-aggregated)model?

Hi,

comments? 
-lasse

---

From: "Lars Westberg" <[email-masked]>
Date: Thu, 3 Apr 2008 16:50:40 +0200

Hi Phil
 
The major problem is that the egress will notice the congestion if a
single marking scheme is used but I think it may be a problem to
calculate the excess rate. 
May be you can check it more in detail.  
 
One of the reason is of cources that we are thinking of deplyment
scenario where the number of edges are very large and I am worried that
the trunk-approach will impose a limitations in the network design. 
 
-Lasse

________________________________

From: [email-masked] [mailto:[email-masked]] 
Sent: den 3 april 2008 09:51
To: Lars Westberg; [email-masked]
Subject: RE: [PCN] Why is PCN only supporting trunk
(ingress-egresss-aggregated)model?

Lasse

phil

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

Hi,

comments? 
-lasse

---

From: "Anna Charny (acharny)" <[email-masked]>
Date: Thu, 3 Apr 2008 11:28:27 -0400

Lars, 
 
Would it not be the case that if you do not have congestion estimates
per ingress-egress pair, you cannot accurately know flows to which
egresses you need to stop admission trigger termination for. 
 
I was under the impression that the reason the trunk mode is needed is
precisely because we do not really 
know how to make the hose model work accurately.  But perhaps I am
missing exactly what you have in mind?
 
Thank you,
Anna 

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Lars Westberg
	Sent: Thursday, April 03, 2008 10:51 AM
	To: [email-masked]; [email-masked]
	Subject: Re: [PCN] Why is PCN only supporting
trunk(ingress-egresss-aggregated)model?

	Hi Phil
	 
	The major problem is that the egress will notice the congestion
if a single marking scheme is used but I think it may be a problem to
calculate the excess rate. 
	May be you can check it more in detail.  
	 
	One of the reason is of cources that we are thinking of
deplyment scenario where the number of edges are very large and I am
worried that the trunk-approach will impose a limitations in the network
design. 
	 
	-Lasse

	Lasse

	To check: the hose model would mean that the admission decision
is made at each ingress node, regardless of what egress the traffic is
destined to. So, a PCN hose model would involve each ingress getting
congestion reports from every egress (for traffic from that ingress) and
recording them as a collected (aggregated) value of pre-congestion. 

	As far as I know, no-one has looked at this - I don't think we
should delay current progress by looking at it, since it seems to me a
significant change to the conceptual model. But it looks to me like an
extension that could easily be done with the pcn technology described in
the architecture draft. 

	phil

	-----Original Message-----
	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Lars Westberg
	Sent: 03 April 2008 06:16
	To: [email-masked]
	Subject: [PCN] Why is PCN only supporting trunk
(ingress-egresss-aggregated)model?

	Hi,

	In am concerned about the scalabillity to large networks. This
is due to the
	N^2 trunk mesh of trunks, where N represents the number of edges
in a network. 
	I think it would be good if PCN could support the HOSE model,
where no aggregation states are used to model a bandwidth limit.
Therefore, I would recommend to look into PCN -extention for HOSE type
scenario.

	comments? 
	-lasse

---

From: <[email-masked]>
Date: Thu, 3 Apr 2008 16:30:30 +0100

Hi lasse

My answer was only about admission ctrl. Actually I'm not sure I get
your scalability worry - after all, in the pcn architecture doc If the
number of edges is really too high for the ingress to keep track of the
pre-congestion level for all the egresses, then it seems very likely
that there'll be no current comms between the ingress & many of the
egresses, and hence no need to track that pre-congestion level

On the subject of flow termination ctrl my instinct is that scalability
is (even?) less of a concern. If it really is, then you could go for
terminating marked flows or a subset, as in michael's EMFT

phil

-----Original Message-----
From: Lars Westberg [mailto:[email-masked]] 
Sent: 03 April 2008 15:51
To: Eardley,PL,Philip,CXR9 R; [email-masked]
Subject: RE: [PCN] Why is PCN only supporting trunk

Hi Phil

-Lasse

Lasse

phil

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

Hi,

comments? 
-lasse

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 4 Apr 2008 09:58:16 +0200

Hi Anna
 
What Lars I think means is that we go forward using the trunk
(ingress-egress-aggregate) model, but 
it should also be possible to work on an experimental RFC that supports the
HOSE model
 
Furthermore, the HOSE model works accurately if:
* the egress is able to have information of the flows that were affected by
the congestion
* the egress is able to calculate the excess rate caused by the congestion 
* the egress is able to select flows that were affected by the congestion
* the egress is able to know the previous ingress hop.
 
By using the features that are currently described in LC-PCN for ECMP
solution and by using per PHB aggregated states at the edges, 
instead of ingress-egress-aggregated states at the edges then the HOSE model
can work accurately.
 
Best regards,
Georgios

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Anna
Charny (acharny)
Sent: donderdag 3 april 2008 17:28
To: Lars Westberg; [email-masked]; [email-masked]
Subject: Re: [PCN] Why is PCN only
supportingtrunk(ingress-egresss-aggregated)model?

Lars, 
 
Would it not be the case that if you do not have congestion estimates per
ingress-egress pair, you cannot accurately know flows to which egresses you
need to stop admission trigger termination for. 
 
I was under the impression that the reason the trunk mode is needed is
precisely because we do not really 
know how to make the hose model work accurately.  But perhaps I am missing
exactly what you have in mind?
 
Thank you,
Anna 

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Lars
Westberg

Hi Phil
 
The major problem is that the egress will notice the congestion if a single
marking scheme is used but I think it may be a problem to calculate the
excess rate. 
May be you can check it more in detail.  
 
One of the reason is of cources that we are thinking of deplyment scenario
where the number of edges are very large and I am worried that the
trunk-approach will impose a limitations in the network design. 
 
-Lasse

  _____  

Lasse

To check: the hose model would mean that the admission decision is made at
each ingress node, regardless of what egress the traffic is destined to. So,
a PCN hose model would involve each ingress getting congestion reports from
every egress (for traffic from that ingress) and recording them as a
collected (aggregated) value of pre-congestion. 

As far as I know, no-one has looked at this - I don't think we should delay
current progress by looking at it, since it seems to me a significant change
to the conceptual model. But it looks to me like an extension that could
easily be done with the pcn technology described in the architecture draft. 

phil

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lars
Westberg
Sent: 03 April 2008 06:16
To: [email-masked]
Subject: [PCN] Why is PCN only supporting trunk
(ingress-egresss-aggregated)model?

Hi,
From the PCN architecture draft that I have read and from the discussions
that I have followed I see that PCN is currently only supporting the trunk
aggregation model, where ingress-egreess-aggregated states are used. Thus
each ingress and egress will use per each ingress - egress set one
aggregated state.

In am concerned about the scalabillity to large networks. This is due to the
N^2 trunk mesh of trunks, where N represents the number of edges in a
network. 
I think it would be good if PCN could support the HOSE model, where no
aggregation states are used to model a bandwidth limit. Therefore, I would
recommend to look into PCN -extention for HOSE type scenario.

comments? 
-lasse

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 4 Apr 2008 10:15:09 +0200

Hi Phil
 
The scalability problem with the trunk model mentioned by Lars is the
following.
Suppose that a network uses 200 ingress/egress edges.
 
In the worst case the edges will have to maintain the following number of
states:
 
Trunk model (max number of state per PHB at edges)
----------------
Max. number of ingress-egress-aggregated states at each ingress: (N-1) = 199
Max. number of ingress-egress-aggregated states at each egress: (N-1)^2 =
39601

HOSE model (max. number of states per PHB at edges)
--------------
Max. number of per PHB states (instead of ingress-egress-aggregates) at each
ingress: (N-1) = 199
Max. number of per PHB states at each egress: (N-1) =  199
 
Regarding flow termination using EMFT, as it was already emphasized during
the IETF meeting, 
EMFT is too slow and it will not able to solve the flow termination
accurately.

Best regards,
Georgios

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: donderdag 3 april 2008 17:31
To: [email-masked]; [email-masked]
Subject: Re: [PCN] Why is PCN only supporting
trunk(ingress-egresss-aggregated)model?

Hi lasse

My answer was only about admission ctrl. Actually I'm not sure I get your
scalability worry - after all, in the pcn architecture doc If the number of
edges is really too high for the ingress to keep track of the pre-congestion
level for all the egresses, then it seems very likely that there'll be no
current comms between the ingress & many of the egresses, and hence no need
to track that pre-congestion level

On the subject of flow termination ctrl my instinct is that scalability is
(even?) less of a concern. If it really is, then you could go for
terminating marked flows or a subset, as in michael's EMFT

phil

-----Original Message-----
From: Lars Westberg [mailto:[email-masked]] 
Sent: 03 April 2008 15:51
To: Eardley,PL,Philip,CXR9 R; [email-masked]
Subject: RE: [PCN] Why is PCN only supporting trunk

Hi Phil

-Lasse

  _____  

Lasse

phil

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

Hi,

comments? 
-lasse

---

From: <[email-masked]>
Date: Fri, 4 Apr 2008 09:21:59 +0100

Without responding to the detail of your msg, I think the important
point made by you & lasse is that you have in mind how to extent PCn to
other deployment models. This is good news - however we should focus on
finishing our current work before we concentrate on extensions.

-----Original Message-----
From: Georgios Karagiannis [mailto:[email-masked]] 
Sent: 04 April 2008 09:15
To: Eardley,PL,Philip,CXR9 R; [email-masked]; [email-masked]
Subject: RE: [PCN] Why is PCN only supporting

Hi Phil

In the worst case the edges will have to maintain the following number
of states:

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

Max. number of ingress-egress-aggregated states at each ingress: (N-1) =
199

Max. number of ingress-egress-aggregated states at each egress: (N-1)^2
=  39601

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

Max. number of per PHB states (instead of ingress-egress-aggregates) at
each ingress: (N-1) = 199

Regarding flow termination using EMFT, as it was already emphasized
during the IETF meeting, 

instead of ingress-egress-aggregated states at the edges then the HOSE
model can work accurately.

Best regards,

Georgios

	

Behalf Of [email-masked]

	Hi lasse

	My answer was only about admission ctrl. Actually I'm not sure I
get your scalability worry - after all, in the pcn architecture doc If
the number of edges is really too high for the ingress to keep track of
the pre-congestion level for all the egresses, then it seems very likely
that there'll be no current comms between the ingress & many of the
egresses, and hence no need to track that pre-congestion level

	On the subject of flow termination ctrl my instinct is that
scalability is (even?) less of a concern. If it really is, then you
could go for terminating marked flows or a subset, as in michael's EMFT

	phil

	-----Original Message-----
	From: Lars Westberg [mailto:[email-masked]] 
	Sent: 03 April 2008 15:51
	To: Eardley,PL,Philip,CXR9 R; [email-masked]
	Subject: RE: [PCN] Why is PCN only supporting trunk

	Hi Phil

	-Lasse

	Lasse

	phil

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

	Hi,

	comments? 
	-lasse

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 4 Apr 2008 11:06:25 +0200

Hi Phil
 
HOSE model.
 
What I wanted to say is that we sould be able to work on LC-PCN as being an
experimental RFC 
that provides and supports the HOSE model. Please note that LC-PCN can
provide these HOSE features.
 
However, in order to do that the interior/core node  should be able to
support the following features:
 
* possibility to do not preferentially drop PCN_marked packets. Note that
PCN_Affected_marking encoded 
   packets can be dropped.
 
* use the N proportion between marked excess rate and measured excess rate
 
* provide PCN_Affected_marking encoding and allow to implement the features
that 
  are required for PCN_Affedcted_Marking.
 
Best regards,
Georgios

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: vrijdag 4 april 2008 10:22
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [PCN] Why is PCN only supporting
trunk(ingress-egresss-aggregated)model?

Without responding to the detail of your msg, I think the important point
made by you & lasse is that you have in mind how to extent PCn to other
deployment models. This is good news - however we should focus on finishing
our current work before we concentrate on extensions.

-----Original Message-----
From: Georgios Karagiannis [mailto:[email-masked]] 
Sent: 04 April 2008 09:15
To: Eardley,PL,Philip,CXR9 R; [email-masked]; [email-masked]
Subject: RE: [PCN] Why is PCN only supporting

Hi Phil

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

 

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

 

Best regards,

Georgios

  _____  

Hi lasse

phil

-----Original Message-----
From: Lars Westberg [mailto:[email-masked]] 
Sent: 03 April 2008 15:51
To: Eardley,PL,Philip,CXR9 R; [email-masked]
Subject: RE: [PCN] Why is PCN only supporting trunk

Hi Phil

-Lasse

  _____  

Lasse

phil

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

Hi,

comments? 
-lasse

---

From: <[email-masked]>
Date: Fri, 4 Apr 2008 10:23:19 +0100

I really strongly disagree that we should work on the hose model now.
The WG is making slower progress than it should because we keep losing
our focus. 

The hose model hasn't been in our PCN discussions for the last 3 or 4
years. I'm unconvinced it's a good thing to work on even in the future.
The normal diffserv architecture (adm ctrl at ingress whatever flow's
destination) seems to cover this, and its focussed overload problem was
one of the motivations for PCN - and its per ingress-egress pair
architecture. 

Of course, once the PCN work is done ie the current charter is finished,
then we can look at what to do next. That surely is the right time to
think about extending pcn to other architectures - and having the
discussion about whether the hose model is a good thing to do.

As regards what features you'd like on the interior nodes, these are
points under discussion that having nothing to do with the hose model.
They were after all discussed before this recent hose discussion. 

Phil/ 

-----Original Message-----
From: Georgios Karagiannis [mailto:[email-masked]] 
Sent: 04 April 2008 10:06
To: Eardley,PL,Philip,CXR9 R; [email-masked]; [email-masked]
Subject: RE: [PCN] Why is PCN only supporting

Hi Phil

it should also be possible to work on an experimental RFC that supports
the HOSE model.

What I wanted to say is that we sould be able to work on LC-PCN as being
an experimental RFC 

* possibility to do not preferentially drop PCN_marked packets. Note
that PCN_Affected_marking encoded 

   packets can be dropped.

* use the N proportion between marked excess rate and measured excess
rate

* provide PCN_Affected_marking encoding and allow to implement the
features that 

Best regards,

Georgios

	 

	To: [email-masked]; [email-masked];
[email-masked]

	Without responding to the detail of your msg, I think the
important point made by you & lasse is that you have in mind how to
extent PCn to other deployment models. This is good news - however we
should focus on finishing our current work before we concentrate on
extensions.

	-----Original Message-----
	From: Georgios Karagiannis [mailto:[email-masked]] 
	Sent: 04 April 2008 09:15
	To: Eardley,PL,Philip,CXR9 R; [email-masked];
[email-masked]

	Hi Phil

	The scalability problem with the trunk model mentioned by Lars
is the following.

	In the worst case the edges will have to maintain the following
number of states:

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

	Max. number of ingress-egress-aggregated states at each ingress:
(N-1) = 199

	Max. number of ingress-egress-aggregated states at each egress:
(N-1)^2 =  39601

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

	Max. number of per PHB states (instead of
ingress-egress-aggregates) at each ingress: (N-1) = 199

	Regarding flow termination using EMFT, as it was already
emphasized during the IETF meeting, 

	EMFT is too slow and it will not able to solve the flow
termination accurately.

	By using the features that are currently described in LC-PCN for
ECMP solution and by using per PHB aggregated states at the edges, 

	instead of ingress-egress-aggregated states at the edges then
the HOSE model can work accurately.

	Best regards,

	Georgios

		

		From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
		Sent: donderdag 3 april 2008 17:31
		To: [email-masked]; [email-masked]
		Subject: Re: [PCN] Why is PCN only supporting
trunk(ingress-egresss-aggregated)model?

		Hi lasse

		My answer was only about admission ctrl. Actually I'm
not sure I get your scalability worry - after all, in the pcn
architecture doc If the number of edges is really too high for the
ingress to keep track of the pre-congestion level for all the egresses,
then it seems very likely that there'll be no current comms between the
ingress & many of the egresses, and hence no need to track that
pre-congestion level

		On the subject of flow termination ctrl my instinct is
that scalability is (even?) less of a concern. If it really is, then you
could go for terminating marked flows or a subset, as in michael's EMFT

		phil

		-----Original Message-----
		From: Lars Westberg [mailto:[email-masked]] 
		Sent: 03 April 2008 15:51
		To: Eardley,PL,Philip,CXR9 R; [email-masked]
		Subject: RE: [PCN] Why is PCN only supporting trunk

		Hi Phil

		The major problem is that the egress will notice the
congestion if a single marking scheme is used but I think it may be a
problem to calculate the excess rate. 

		-Lasse

		From: [email-masked]
[mailto:[email-masked]] 
		Sent: den 3 april 2008 09:51
		To: Lars Westberg; [email-masked]
		Subject: RE: [PCN] Why is PCN only supporting trunk
(ingress-egresss-aggregated)model?

		Lasse

		To check: the hose model would mean that the admission
decision is made at each ingress node, regardless of what egress the
traffic is destined to. So, a PCN hose model would involve each ingress
getting congestion reports from every egress (for traffic from that
ingress) and recording them as a collected (aggregated) value of
pre-congestion. 

		As far as I know, no-one has looked at this - I don't
think we should delay current progress by looking at it, since it seems
to me a significant change to the conceptual model. But it looks to me
like an extension that could easily be done with the pcn technology
described in the architecture draft. 

		phil

		-----Original Message-----
		From: [email-masked] [mailto:[email-masked]]
On Behalf Of Lars Westberg
		Sent: 03 April 2008 06:16
		To: [email-masked]
		Subject: [PCN] Why is PCN only supporting trunk
(ingress-egresss-aggregated)model?

		Hi,
		From the PCN architecture draft that I have read and
from the discussions that I have followed I see that PCN is currently
only supporting the trunk aggregation model, where
ingress-egreess-aggregated states are used. Thus each ingress and egress
will use per each ingress - egress set one aggregated state.

		In am concerned about the scalabillity to large
networks. This is due to the
		N^2 trunk mesh of trunks, where N represents the number
of edges in a network. 
		I think it would be good if PCN could support the HOSE
model, where no aggregation states are used to model a bandwidth limit.
Therefore, I would recommend to look into PCN -extention for HOSE type
scenario.

		comments? 
		-lasse

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 4 Apr 2008 12:08:29 +0200

Hi Phil
 
Please note that HOSE model is not out of the scope of the PCN charter. The
PCN charter is 
not in favour of the trunk (pipe) or the HOSE model. Therefore, I do not
think that 
PCN rechartering is needed for this purpose.
 
Of course we can all work on the short term to finalise the standard PCN
solution.
 
However, what I would like to see now (in the short term)
is that the interior/core router should provide the possibilities and
features to use the HOSE model.
 
Note that the following features when supported can provide solutions to two
issues. Solution to the HOSE model 
and to the ECMP problem.
I think therefore, that these features are really providing an added value
to both SM and CL-PHB schemes.
 
The required features in the interior/core are:

   packets can be dropped.

Best regards,

Georgios

 

  _____  

Sent: vrijdag 4 april 2008 11:23

I really strongly disagree that we should work on the hose model now. The WG
is making slower progress than it should because we keep losing our focus. 

The hose model hasn't been in our PCN discussions for the last 3 or 4 years.
I'm unconvinced it's a good thing to work on even in the future. The normal
diffserv architecture (adm ctrl at ingress whatever flow's destination)
seems to cover this, and its focussed overload problem was one of the
motivations for PCN - and its per ingress-egress pair architecture. 

Of course, once the PCN work is done ie the current charter is finished,
then we can look at what to do next. That surely is the right time to think
about extending pcn to other architectures - and having the discussion about
whether the hose model is a good thing to do.

As regards what features you'd like on the interior nodes, these are points
under discussion that having nothing to do with the hose model. They were
after all discussed before this recent hose discussion. 

Phil/ 

-----Original Message-----
From: Georgios Karagiannis [mailto:[email-masked]] 
Sent: 04 April 2008 10:06
To: Eardley,PL,Philip,CXR9 R; [email-masked]; [email-masked]
Subject: RE: [PCN] Why is PCN only supporting

Hi Phil

   packets can be dropped.

Best regards,

Georgios

 

  _____  

-----Original Message-----
From: Georgios Karagiannis [mailto:[email-masked]] 
Sent: 04 April 2008 09:15
To: Eardley,PL,Philip,CXR9 R; [email-masked]; [email-masked]
Subject: RE: [PCN] Why is PCN only supporting

Hi Phil

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

 

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

 

Best regards,

Georgios

  _____  

Hi lasse

phil

-----Original Message-----
From: Lars Westberg [mailto:[email-masked]] 
Sent: 03 April 2008 15:51
To: Eardley,PL,Philip,CXR9 R; [email-masked]
Subject: RE: [PCN] Why is PCN only supporting trunk

Hi Phil

-Lasse

  _____  

Lasse

phil

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

Hi,

comments? 
-lasse

---

From: <[email-masked]>
Date: Fri, 4 Apr 2008 11:33:50 +0100

Excellent, let's continue having these discussions about the interior
node's behaviour without referring to the hose model. 

-----Original Message-----
From: Georgios Karagiannis [mailto:[email-masked]] 
Sent: 04 April 2008 11:08
To: Eardley,PL,Philip,CXR9 R; [email-masked]; [email-masked]
Subject: RE: [PCN] Why is PCN only supporting

Hi Phil

Please note that HOSE model is not out of the scope of the PCN charter.
The PCN charter is 

Note that the following features when supported can provide solutions to
two issues. Solution to the HOSE model 

and to the ECMP problem.

I think therefore, that these features are really providing an added
value to both SM and CL-PHB schemes.

   packets can be dropped.

Best regards,

Georgios

 

	

	I really strongly disagree that we should work on the hose model
now. The WG is making slower progress than it should because we keep
losing our focus. 

	The hose model hasn't been in our PCN discussions for the last 3
or 4 years. I'm unconvinced it's a good thing to work on even in the
future. The normal diffserv architecture (adm ctrl at ingress whatever
flow's destination) seems to cover this, and its focussed overload
problem was one of the motivations for PCN - and its per ingress-egress
pair architecture. 

	Of course, once the PCN work is done ie the current charter is
finished, then we can look at what to do next. That surely is the right
time to think about extending pcn to other architectures - and having
the discussion about whether the hose model is a good thing to do.

	As regards what features you'd like on the interior nodes, these
are points under discussion that having nothing to do with the hose
model. They were after all discussed before this recent hose discussion.

	Phil/ 

	-----Original Message-----
	From: Georgios Karagiannis [mailto:[email-masked]] 
	Sent: 04 April 2008 10:06
	To: Eardley,PL,Philip,CXR9 R; [email-masked];
[email-masked]

	Hi Phil

	it should also be possible to work on an experimental RFC that
supports the HOSE model.

	What I wanted to say is that we sould be able to work on LC-PCN
as being an experimental RFC 

	that provides and supports the HOSE model. Please note that
LC-PCN can provide these HOSE features.

	However, in order to do that the interior/core node  should be
able to support the following features:

	* possibility to do not preferentially drop PCN_marked packets.
Note that PCN_Affected_marking encoded 

	   packets can be dropped.

	* use the N proportion between marked excess rate and measured
excess rate

	* provide PCN_Affected_marking encoding and allow to implement
the features that 

	Best regards,

	Georgios

		 

		Without responding to the detail of your msg, I think
the important point made by you & lasse is that you have in mind how to
extent PCn to other deployment models. This is good news - however we
should focus on finishing our current work before we concentrate on
extensions.

		-----Original Message-----
		From: Georgios Karagiannis
[mailto:[email-masked]] 
		Sent: 04 April 2008 09:15
		To: Eardley,PL,Philip,CXR9 R;
[email-masked]; [email-masked]
		Subject: RE: [PCN] Why is PCN only supporting
trunk(ingress-egresss-aggregated)model?

		Hi Phil

		The scalability problem with the trunk model mentioned
by Lars is the following.

		In the worst case the edges will have to maintain the
following number of states:

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

		Max. number of ingress-egress-aggregated states at each
ingress: (N-1) = 199

		Max. number of ingress-egress-aggregated states at each
egress: (N-1)^2 =  39601

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

		Max. number of per PHB states at each egress: (N-1) =
199

		By using the features that are currently described in
LC-PCN for ECMP solution and by using per PHB aggregated states at the
edges, 

		instead of ingress-egress-aggregated states at the edges
then the HOSE model can work accurately.

		Best regards,

		Georgios

			

			From: [email-masked]
[mailto:[email-masked]] On Behalf Of [email-masked]
			Sent: donderdag 3 april 2008 17:31
			To: [email-masked]; [email-masked]
			Subject: Re: [PCN] Why is PCN only supporting
trunk(ingress-egresss-aggregated)model?

			Hi lasse

			My answer was only about admission ctrl.
Actually I'm not sure I get your scalability worry - after all, in the
pcn architecture doc If the number of edges is really too high for the
ingress to keep track of the pre-congestion level for all the egresses,
then it seems very likely that there'll be no current comms between the
ingress & many of the egresses, and hence no need to track that
pre-congestion level

			On the subject of flow termination ctrl my
instinct is that scalability is (even?) less of a concern. If it really
is, then you could go for terminating marked flows or a subset, as in
michael's EMFT

			phil

			-----Original Message-----
			From: Lars Westberg
[mailto:[email-masked]] 
			Sent: 03 April 2008 15:51
			To: Eardley,PL,Philip,CXR9 R; [email-masked]
			Subject: RE: [PCN] Why is PCN only supporting
trunk (ingress-egresss-aggregated)model?

			Hi Phil

			The major problem is that the egress will notice
the congestion if a single marking scheme is used but I think it may be
a problem to calculate the excess rate. 

			One of the reason is of cources that we are
thinking of deplyment scenario where the number of edges are very large
and I am worried that the trunk-approach will impose a limitations in
the network design. 

			-Lasse

trunk (ingress-egresss-aggregated)model?

			Lasse

			To check: the hose model would mean that the
admission decision is made at each ingress node, regardless of what
egress the traffic is destined to. So, a PCN hose model would involve
each ingress getting congestion reports from every egress (for traffic
from that ingress) and recording them as a collected (aggregated) value
of pre-congestion. 

			As far as I know, no-one has looked at this - I
don't think we should delay current progress by looking at it, since it
seems to me a significant change to the conceptual model. But it looks
to me like an extension that could easily be done with the pcn
technology described in the architecture draft. 

			phil

			-----Original Message-----
			From: [email-masked]
[mailto:[email-masked]] On Behalf Of Lars Westberg
			Sent: 03 April 2008 06:16
			To: [email-masked]
			Subject: [PCN] Why is PCN only supporting trunk
(ingress-egresss-aggregated)model?

			Hi,
			From the PCN architecture draft that I have read
and from the discussions that I have followed I see that PCN is
currently only supporting the trunk aggregation model, where
ingress-egreess-aggregated states are used. Thus each ingress and egress
will use per each ingress - egress set one aggregated state.

			In am concerned about the scalabillity to large
networks. This is due to the
			N^2 trunk mesh of trunks, where N represents the
number of edges in a network. 
			I think it would be good if PCN could support
the HOSE model, where no aggregation states are used to model a
bandwidth limit. Therefore, I would recommend to look into PCN
-extention for HOSE type scenario.

			comments? 
			-lasse

---

From: Steven Blake <[email-masked]>
Date: Fri, 04 Apr 2008 08:07:45 -0400

> Trunk model (max number of state per PHB at edges)

I don't believe this is correct.  There are a total of (N-1)^2
ingress/egress aggregates in the network, but each egress terminates
only N-1.

> Max. number of per PHB states (instead of ingress-egress-aggregates)
> at each ingress: (N-1) = 199

Please explain.

Note also that, unless traffic is tunneled from the ingress to egress,
then each egress will have to maintain state for each PCN flow
traversing it, so as to be able to associate an ingress router with the
flow.

Regards,

// Steve

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 4 Apr 2008 15:09:26 +0200

Hi Steven

Please see below 

> From: Steven Blake [mailto:[email-masked]] 
> Sent: vrijdag 4 april 2008 14:08
> To: Georgios Karagiannis
> Cc: [email-masked]; [email-masked]; [email-masked]
> ingress: (N-1) 
> > = 199 Max. number of ingress-egress-aggregated states at 
> each egress:
> > (N-1)^2 =  39601
> 
> I don't believe this is correct.  There are a total of 
> (N-1)^2 ingress/egress aggregates in the network, but each 
> egress terminates only N-1.

The situation that Lars described was a full meshed trunk model!
This will mean that each ingress could also route packets through other
ingresses (by using e.g.
preconfiguration) before they are sent to the egress.

Thus if you have a network with 3 ingresses and one egress, then the total
number of paths 
that the egress is receiveing is 9.
Ingress1 => egress
Ingress2 => egress
Ingress3 => egress
Ingress1 => Ingress2 => egress
Ingress1 => Ingress3 => egress
Ingress2 => Ingress1 => egress
Ingress2 => Ingress3 => egress
Ingress3 => Ingress1 => egress
Ingress3 => Ingress2 => egress

Best regards,
Georgios

> ingress-egress-aggregates) 
> > at each ingress: (N-1) = 199 Max. number of per PHB states at each 
> > egress: (N-1) =  199
> 
> Please explain.
> 
> Note also that, unless traffic is tunneled from the ingress 
> to egress, then each egress will have to maintain state for 
> each PCN flow traversing it, so as to be able to associate an 
> ingress router with the flow.
> 
> 
> Regards,
> 
> // Steve
>

---

From: Steven Blake <[email-masked]>
Date: Fri, 4 Apr 2008 11:17:15 -0400

> Ingress3 => Ingress2 => egress

Georgios,

- You only have more than three paths in the case of ECMP, in which case you
  may have many more than nine.  

- Why only consider the case where traffic is routed via one more ingress, 
  instead of two/three/four/etc.?  

- How and why would the egress distinguish between traffic that entered the 
  network via an ingress X, and traffic that entered by another ingress Y 
  that was routed via X?

Regards,

// Steve

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 4 Apr 2008 17:28:40 +0200

Hi Steven

Please see in line!

> Sent: vrijdag 4 april 2008 17:17
> To: Georgios Karagiannis
> > > (N-1)^2 ingress/egress aggregates in the network, but each egress 
> > > terminates only N-1.
> > 
> > This will mean that each ingress could also route packets through 
> > other ingresses (by using e.g.
> > Thus if you have a network with 3 ingresses and one egress, 
> then the 
> > total number of paths that the egress is receiveing is 9.
> > Ingress1 => egress
> > Ingress2 => egress
> > Ingress3 => egress

Georgios: Yes, you are right, so you get more ingress-egress states

>   instead of two/three/four/etc.?  

Georgios: Yes, you are right, so you get more ingress-egress states
>   network via an ingress X, and traffic that entered by 

Georgios: It is because the flows passing through the different ingresses
and are 
routed to the same egress might follow a different path. 
Thus the flows that are forwarded through the following path:
IngressX => Egress
Might follow a different path then the flows that were routed via:
IngressY => IngressX => Egress

Best regards,
Georgios

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Sat, 05 Apr 2008 12:33:04 +0000

Hi all

I have checked the below calculations made by me and I think that I have

>Trunk model (max number of state per PHB at edges)

Georgios: The above caluclation regarding number of
ingress-egress-aggregated states at each egress is only valid if the
following is valid:
* A full meshed trunk model is used.
This will mean that each ingress could also route packets through other
ingresses (by using e.g.
preconfiguration) before they are sent to the egress.

* Flows passing through the different ingresses and are routed to the
same egress might follow a different path.
Thus the flows that are forwarded through the following path:
IngressX => Egress
Might follow a different path then the flows that were routed via:
IngressY => IngressX => Egress
By having separate ingress-egress states for such situations, it prevents
the actions where flows that are belonging to one congested
ingress-egress aggregate trunk, but are not passing through the same
communication path as the congested trunk, are used in solving the
congestion in the ingress-egress-aggregated trunk. In the above example
IngressX and Egress will then have to maintain two types of aggregation
states.
IngressX-Egress state
IngressY-IngressX-Egress state.

>HOSE model (max. number of states per PHB at edges)

Georgios: The above calculation was related to the number of PHB states
on all edges used in this example.
Note that:
Max. number of per PHB states at each ingress: = 1 PHB state (this holds
for any example).
Max. number of per PHB states at each egress: = 1 PHB state (this holds
for any example)

Furthermore, note that when an egress based admission control and flow
termination handling solution, such as LC-PCN, is used for the support
of the HOSE model, then the PCN domain can use any kind of routing.
Thus this type of HOSE model is routing agnostic.

Best regards,
Georgios