Subject: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt

From: Steven Blake <[email-masked]>
Date: Fri, 08 Aug 2008 20:03:40 -0400

This message starts a 2+-week PCN working group last call for advancing

        Title           : Pre-Congestion Notification Architecture
        Author(s)       : P. Eardley
        Filename        : draft-ietf-pcn-architecture-05.txt
        Pages           : 54
        Date            : 2008-08-07

as an Informational RFC.  Substantive comments and statements of support
for this draft should be sent to the pcn mailing list.  Editorial
suggestions can be sent directly to the document editor.  
The last call will end on Wednesday August 27.

// Steve

_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: Steven Blake <[email-masked]>
Date: Fri, 22 Aug 2008 08:35:19 -0400

> The last call will end on Wednesday August 27.

A reminder that this last call closes next Wednesday.

Regards,

// Steve

---

From: <[email-masked]>
Date: Sat, 23 Aug 2008 14:47:20 +0100

I support this document going to RFC in its current form (obviously allowing for any nits other people may have picked up).
 
Toby

________________________________

From: [email-masked] on behalf of Steven Blake
Sent: Fri 22/08/2008 13:35
To: pcn
Subject: Re: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt

Regards,

// Steve

---

From: "Geib, Ruediger" <[email-masked]>
Date: Mon, 25 Aug 2008 16:53:07 +0200

Steven,

thanks for the reminder. I agree to publish draft-ietf-pcn-architecture-05.txt as
an informational RFC.

My thanks to Phil and the other contributors for their work.

Regards,

Ruediger

One proposed rewording and some editorials I found:

Section 4. Deployment scenarios,

Page 10, top section, last sentence:

   "The drawback of this
   approach would be that until PCN-traffic naturally departs to relieve
   the congestion, all PCN-flows as well as lower priority services will
   be adversely affected."

May sound better with the following:

   The drawback of this
   approach would be that until PCN-traffic naturally drops below PCN
                                                      ^^^^^^^^^^^^^^^^ 
   scheduler rate, all PCN-flows as well as lower priority services will
   ^^^^^^^^^^^^^^
   be adversely affected. 

-----

Same page (page 10), last section, last sentence:

   "A similar example
   would use NSIS signalling is used instead of RSVP."
                             ^^^^^^^^
Delete the marked words.

-------

Section 5.2 Assumption 2: Real-time....

2nd sentence:

   "We assume that PCN-packets come from real
   time applications generating inelastic traffic, ie it sends packets..."
        ^^^^^^^^^^^^                                  ^^

Does singular "it" refer to plural "applications"?

------

Section 7.2 PCN-ingress-node functions

2nd bullet point, last sentence:

      "Similarly, police packets that are part of
      a previously admitted flow, to check that the flow keeps to the
      agreed rate or flowspec (eg RFC1633 [RFC1633] for a microflow and
      its NSIS equivalent).  If PCN"
                           ^^^^^^^^
Delete the two words or make it a sentence.

--------

Section 9.1.2 Parameters
Page 32, 3rd section from top, last sentence

   "It will be preferable for their to be
                              ^^^^^^^^^^^^
   rules to set defaults for these parameters, but then allow operators
   to change them, for instance if average traffic characteristics
   change over time."

Something is missing at the marked part of that sentence.

--------

A general obeservation:
On lists, "." terminates the last sentence or not. Doesn't bother me, just 
be aware if anybody cares for such minor issues.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Steven Blake
Sent: Friday, August 22, 2008 2:35 PM
To: pcn
Subject: Re: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt

Regards,

// Steve

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 26 Aug 2008 11:44:33 +0000

Hi Phil, Hi all

Here are some  comments on the PCN architecture draft:

1) Thank you for clarifying the bullet in Setion 3.2 about flow
termination.

2) From what I understand the PCN architecture draft mentions that PCN
supports only the trunk (ingress-egress-aggregate) and not the HOSE
model.
Is the PCN architecture draft excluding solutions that support the HOSE
model? If not, please emphasize in the PCN architecture draft that
"solutions that are based on other types of flow aggregation than the
ingress-egress-aggregate method of flow aggregation, are not excluded
from the PCN WG activities."

3) The architecture draft excludes the possibility of using the
PCN-Affected marking encoding. From a previous email driscussion I have
understood from you that
the PCN WG does not exclude the possibility of extending the three
encoding states (mentioned currently in the PCN architecture draft) with
one additional encoding state. Therefore, please emphasize in the PCN
architecture draft that a fourth encoding state can be definedas an
extension, e.g., PCN-Affected marking if the PCN WG decides to provide
solutions tothe ECMP solution.

4) From what I understood the PCN architecture draft emphasizes that the
selected encoding is implemented by a combination of the DSCP and ECN
bits. Has this point been decided by the PCN WG.

Best regards,
Georgios

---

From: <[email-masked]>
Date: Tue, 26 Aug 2008 12:59:21 +0100

{ -----Original Message-----
{ From: [email-masked] [mailto:[email-masked]] On Behalf Of
{ Georgios Karagiannis
{ Sent: 26 August 2008 12:45
{ To: [email-masked]
{ Subject: Re: [PCN] PCN WG last call for
draft-ietf-pcn-architecture-05.txt
{ 
{ Hi Phil, Hi all
{ 
{ Here are some  comments on the PCN architecture draft:
{ 
{ 1) Thank you for clarifying the bullet in Setion 3.2 about flow
{ termination.
{ 
{ 2) From what I understand the PCN architecture draft mentions that PCN
{ supports only the trunk (ingress-egress-aggregate) and not the HOSE
{ model.
{ Is the PCN architecture draft excluding solutions that support the
HOSE
{ model? If not, please emphasize in the PCN architecture draft that
{ "solutions that are based on other types of flow aggregation than the
{ ingress-egress-aggregate method of flow aggregation, are not excluded
{ from the PCN WG activities."

Could you explain a bit more what you mean here please? Not quite sure
what your model is.
2 geeneral points:
[1] I'm not sure we should raise possibilities that haven't been
analysed & had simulations behind them. 
[2] this is an INFO architectural draft - people are can use the STDS
pieces in other ways. 

{ 
{ 
{ 3) The architecture draft excludes the possibility of using the
{ PCN-Affected marking encoding. From a previous email driscussion I
have
{ understood from you that
{ the PCN WG does not exclude the possibility of extending the three
{ encoding states (mentioned currently in the PCN architecture draft)
with
{ one additional encoding state. Therefore, please emphasize in the PCN
{ architecture draft that a fourth encoding state can be definedas an
{ extension, e.g., PCN-Affected marking if the PCN WG decides to provide
{ solutions tothe ECMP solution.

Encoding states are little mentioned in the draft. I tried to only
assume what's in the baseline encoding, which involved some changes in
the -04 to -05 version.

I'm not sure what part you think needs changing. Perhaps near the end of
S1:
<The "baseline" encoding is standardised in
[I-D.moncaster-pcn-baseline-encoding], which standardises two PCN
encoding states (PCN-marked and not PCN-marked), whilst (experimental)
extensions to the baseline encoding can provide three encoding states
(threshold-marked, excess-traffic-marked, not PCN-marked).>

I could add to this sentence:-
"or perhaps further encoding states as suggested in [LC-PCN]"

{ 
{ 
{ 4) From what I understood the PCN architecture draft emphasizes that
the
{ selected encoding is implemented by a combination of the DSCP and ECN
{ bits. Has this point been decided by the PCN WG.

Well the WG has decided on the baseline encoding, which does indeed use
a combination of dscp & ecn bits. 

Thanks for the comments
phil

{ 
{ 
{ Best regards,
{ Georgios
{ 
{ 
{ 
{ On 8/22/2008, "Steven Blake" <[email-masked]> wrote:
{ 
{ >On Fri, 2008-08-08 at 20:03 -0400, Steven Blake wrote:
{ >
{ >> This message starts a 2+-week PCN working group last call for
advancing
{ >>
{ >>         Title           : Pre-Congestion Notification Architecture
{ >>         Author(s)       : P. Eardley
{ >>         Filename        : draft-ietf-pcn-architecture-05.txt
{ >>         Pages           : 54
{ >>         Date            : 2008-08-07
{ >>
{ >> as an Informational RFC.  Substantive comments and statements of
{ support
{ >> for this draft should be sent to the pcn mailing list.  Editorial
{ >> suggestions can be sent directly to the document editor.
{ >> The last call will end on Wednesday August 27.
{ >
{ >A reminder that this last call closes next Wednesday.
{ >
{ >
{ >Regards,
{ >
{ >// Steve
{ >
{ >_______________________________________________
{ >PCN mailing list
{ >[email-masked]
{ >https://www.ietf.org/mailman/listinfo/pcn
{ _______________________________________________
{ PCN mailing list
{ [email-masked]
{ https://www.ietf.org/mailman/listinfo/pcn
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: Steven Blake <[email-masked]>
Date: Tue, 26 Aug 2008 08:46:17 -0400

> from the PCN WG activities."

Actually they are, by our charter.

Regards,

// Steve

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 26 Aug 2008 16:11:50 +0200

Hi Steven 

Please see in line!

> From: Steven Blake [mailto:[email-masked]] 
> Sent: dinsdag 26 augustus 2008 14:46
> To: Georgios Karagiannis
> Cc: [email-masked]
> > Is the PCN architecture draft excluding solutions that support the 
> > HOSE model? If not, please emphasize in the PCN architecture draft 
> > that "solutions that are based on other types of flow 
> aggregation than 
> > the ingress-egress-aggregate method of flow aggregation, are not 
> > excluded from the PCN WG activities."
> 

I have not seen that the PCN charter excludes other types of aggregation.
Please note 
that I am refering to the HOSE model where the traffic sent by one or more
than one ingresses towards one egress 
is aggregated at the egress. In this way higgher traffic aggregation can be
accomplished than in the situation 
that the pipe/trunk (ingress-egress-aggregate) is used, where the traffic
sent by only one ingress in aggegated at the egress.

Best regards,
Georgios

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 26 Aug 2008 16:15:51 +0200

Hi Phil 

Please see in line!

> From: [email-masked] [mailto:[email-masked]] 
> Sent: dinsdag 26 augustus 2008 13:59
> To: [email-masked]; [email-masked]
> Subject: RE: [PCN] PCN WG last call for 
> { From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of { Georgios Karagiannis { Sent: 26 August 2008 12:45 
> { To: [email-masked] { Subject: Re: [PCN] PCN WG last call for 
> { 1) Thank you for clarifying the bullet in Setion 3.2 about 
> flow { termination.
> {
> { 2) From what I understand the PCN architecture draft 
> mentions that PCN { supports only the trunk 
> (ingress-egress-aggregate) and not the HOSE { model.
> { Is the PCN architecture draft excluding solutions that 
> support the HOSE { model? If not, please emphasize in the PCN 
> architecture draft that { "solutions that are based on other 
> types of flow aggregation than the { ingress-egress-aggregate 
> method of flow aggregation, are not excluded { from the PCN 
> WG activities."
> 
> Could you explain a bit more what you mean here please? Not 
> quite sure what your model is.
> 2 geeneral points:
> [1] I'm not sure we should raise possibilities that haven't 
> been analysed & had simulations behind them. 
> [2] this is an INFO architectural draft - people are can use 
> the STDS pieces in other ways. 

Georgios: I am refering to the HOSE model:
Please note that I am refering to the HOSE model where the traffic sent by
one or more than one ingresses towards one egress is aggregated at the
(receiveing) 
 egress. In this way higher traffic aggregation can be accomplished than in
the situation that the pipe/trunk (ingress-egress-aggregate) is used, where
the traffic sent by only one ingress is aggegated at the (receiving) egress.
> 
> {
> {
> { 3) The architecture draft excludes the possibility of using 
> the { PCN-Affected marking encoding. From a previous email 
> driscussion I have { understood from you that { the PCN WG 
> does not exclude the possibility of extending the three { 
> encoding states (mentioned currently in the PCN architecture 
> draft) with { one additional encoding state. Therefore, 
> please emphasize in the PCN { architecture draft that a 
> fourth encoding state can be definedas an { extension, e.g., 
> PCN-Affected marking if the PCN WG decides to provide { 
> Encoding states are little mentioned in the draft. I tried to 
> only assume what's in the baseline encoding, which involved 
> some changes in the -04 to -05 version.
> 
> [I-D.moncaster-pcn-baseline-encoding], which standardises two 
> PCN encoding states (PCN-marked and not PCN-marked), whilst 
> (experimental) extensions to the baseline encoding can 
> provide three encoding states (threshold-marked, 
> excess-traffic-marked, not PCN-marked).>
> 

[Georgios] This is great!

Best regards,
Georgios

> 
> 
> {
> {
> { 4) From what I understood the PCN architecture draft 
> emphasizes that the { selected encoding is implemented by a 
> combination of the DSCP and ECN { bits. Has this point been 
> decided by the PCN WG.
> 
> Well the WG has decided on the baseline encoding, which does 
> indeed use a combination of dscp & ecn bits. 

Georgios: Was this during the IETF meeting?

Best regards,
Georgios

> { >> This message starts a 2+-week PCN working group last 
> call for advancing { >>
> { >> as an Informational RFC.  Substantive comments and 
> statements of { support { >> for this draft should be sent to 
> the pcn mailing list.  Editorial { >> suggestions can be sent 
> directly to the document editor.

---

From: <[email-masked]>
Date: Tue, 26 Aug 2008 15:28:54 +0100

{ > { 4) From what I understood the PCN architecture draft
{ > emphasizes that the { selected encoding is implemented by a
{ > combination of the DSCP and ECN { bits. Has this point been
{ > decided by the PCN WG.
{ >
{ > Well the WG has decided on the baseline encoding, which does
{ > indeed use a combination of dscp & ecn bits.
{ 
{ Georgios: Was this during the IETF meeting?

As far as I remember, the baseline encoding was agreed in Philadelphia,
confirmed on the list, and re-confirmed in Dublin. 

{ 
{ Best regards,
{ Georgios
{ 
{ >
{ > Thanks for the comments
{ > phil
{ >
{ > {
{ > {
{ > { Best regards,
{ > { Georgios
{ > {
{ > {
{ > {
{ > { On 8/22/2008, "Steven Blake" <[email-masked]> wrote:
{ > {
{ > { >On Fri, 2008-08-08 at 20:03 -0400, Steven Blake wrote:
{ > { >
{ > { >> This message starts a 2+-week PCN working group last
{ > call for advancing { >>
{ > { >>         Title           : Pre-Congestion Notification
{ > Architecture
{ > { >>         Author(s)       : P. Eardley
{ > { >>         Filename        : draft-ietf-pcn-architecture-05.txt
{ > { >>         Pages           : 54
{ > { >>         Date            : 2008-08-07
{ > { >>
{ > { >> as an Informational RFC.  Substantive comments and
{ > statements of { support { >> for this draft should be sent to
{ > the pcn mailing list.  Editorial { >> suggestions can be sent
{ > directly to the document editor.
{ > { >> The last call will end on Wednesday August 27.
{ > { >
{ > { >A reminder that this last call closes next Wednesday.
{ > { >
{ > { >
{ > { >Regards,
{ > { >
{ > { >// Steve
{ > { >
{ > { >_______________________________________________
{ > { >PCN mailing list
{ > { >[email-masked]
{ > { >https://www.ietf.org/mailman/listinfo/pcn
{ > { _______________________________________________
{ > { PCN mailing list
{ > { [email-masked]
{ > { https://www.ietf.org/mailman/listinfo/pcn
{ >
{

---

From: Steven Blake <[email-masked]>
Date: Wed, 27 Aug 2008 00:18:18 -0400

> I have not seen that the PCN charter excludes other types of aggregation.

Well, I checked, and you are correct (mea culpa).

> sent by only one ingress in aggegated at the egress.

Typically the "hose" model refers to point-to-multipoint traffic flow,
not multipoint-to-point.

Regards,

// Steve

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 27 Aug 2008 09:54:23 +0200

Hi Steven 

> Sent: woensdag 27 augustus 2008 6:18
> To: Georgios Karagiannis
> Cc: [email-masked]
> > > > supports only the trunk (ingress-egress-aggregate) and not the 
> > > > HOSE model.
Georgios: No problem

> 
> > Please note
> > that I am refering to the HOSE model where the traffic sent 
> by one or 
> > more than one ingresses towards one egress is aggregated at the 
> > egress. In this way higgher traffic aggregation can be accomplished 
> > than in the situation that the pipe/trunk 
> (ingress-egress-aggregate) 
> > is used, where the traffic sent by only one ingress in aggegated at 
> > the egress.
> 
> Typically the "hose" model refers to point-to-multipoint 
> traffic flow, not multipoint-to-point.
Georgios: Typically yes, but in this case we refer to bandwidth allocation
in a multipoint-to-point fashion.

---

From: <[email-masked]>
Date: Wed, 27 Aug 2008 09:19:30 +0100

So the question is about adding to the draft: 
A model where the egress measures marks coming from all the ingresses,
and makes admission decision based on that.

Before adding anything about this to the draft, I'd like to understand
if this is a genuine practical, understood option (if so, OK), or if
it's a theoretical possibility or one not well understood. 
(there are many things in the latter category that aren't mentioned in
the draft.)

Questions are why this is interesting, why is it better than the models
already well-known, are there comparative analysis /simulations?

I suppose I've got 2 general issues:
[1] every time something is added, overall the document becomes harder
to understand, more daunting to read & it looks less like the WG has
consensus.
[2] this is an INFO doc. People are free to invent ways of using the
standards pieces other than the architecture draft says, and indeed in
ways not yet dreamt of. 

Phil.

{ -----Original Message-----
{ From: [email-masked] [mailto:[email-masked]] On Behalf Of
{ Georgios Karagiannis
{ Sent: 27 August 2008 08:54
{ To: 'Steven Blake'
{ Cc: [email-masked]
{ Subject: Re: [PCN] PCN WG last call for
draft-ietf-pcn-architecture-05.txt
{ 
{ Hi Steven
{ 
{ > -----Original Message-----
{ > From: Steven Blake [mailto:[email-masked]]
{ > Sent: woensdag 27 augustus 2008 6:18
{ > To: Georgios Karagiannis
{ > Cc: [email-masked]
{ > Subject: RE: [PCN] PCN WG last call for
{ > draft-ietf-pcn-architecture-05.txt
{ >
{ > On Tue, 2008-08-26 at 16:11 +0200, Georgios Karagiannis wrote:
{ >
{ > > Hi Steven
{ > >
{ > >
{ > > Please see in line!
{ > >
{ > >
{ > > > -----Original Message-----
{ > > > From: Steven Blake [mailto:[email-masked]]
{ > > > Sent: dinsdag 26 augustus 2008 14:46
{ > > > To: Georgios Karagiannis
{ > > > Cc: [email-masked]
{ > > > Subject: Re: [PCN] PCN WG last call for
{ > > > draft-ietf-pcn-architecture-05.txt
{ > > >
{ > > > On Tue, 2008-08-26 at 11:44 +0000, Georgios Karagiannis wrote:
{ > > >
{ > > > > Hi Phil, Hi all
{ > > > >
{ > > > > Here are some  comments on the PCN architecture draft:
{ > > > >
{ > > > > 1) Thank you for clarifying the bullet in Setion 3.2 about
flow
{ > > > > termination.
{ > > > >
{ > > > > 2) From what I understand the PCN architecture draft
{ > > > mentions that PCN
{ > > > > supports only the trunk (ingress-egress-aggregate) and not the
{ > > > > HOSE model.
{ > > > > Is the PCN architecture draft excluding solutions that
{ > support the
{ > > > > HOSE model? If not, please emphasize in the PCN
{ > architecture draft
{ > > > > that "solutions that are based on other types of flow
{ > > > aggregation than
{ > > > > the ingress-egress-aggregate method of flow
{ > aggregation, are not
{ > > > > excluded from the PCN WG activities."
{ > > >
{ > > > Actually they are, by our charter.
{ > >
{ > > I have not seen that the PCN charter excludes other types
{ > of aggregation.
{ >
{ > Well, I checked, and you are correct (mea culpa).
{ Georgios: No problem
{ 
{ >
{ > > Please note
{ > > that I am refering to the HOSE model where the traffic sent
{ > by one or
{ > > more than one ingresses towards one egress is aggregated at the
{ > > egress. In this way higgher traffic aggregation can be
accomplished
{ > > than in the situation that the pipe/trunk
{ > (ingress-egress-aggregate)
{ > > is used, where the traffic sent by only one ingress in aggegated
at
{ > > the egress.
{ >
{ > Typically the "hose" model refers to point-to-multipoint
{ > traffic flow, not multipoint-to-point.
{ Georgios: Typically yes, but in this case we refer to bandwidth
allocation
{ in a multipoint-to-point fashion.
{ 
{ >
{ >
{ > Regards,
{ >
{ > // Steve
{ >
{ 
{ 
{ _______________________________________________
{ PCN mailing list
{ [email-masked]
{ https://www.ietf.org/mailman/listinfo/pcn
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 27 Aug 2008 10:41:22 +0200

Hi Phil

What I explained is the well know HOSE bandwidth management model.
During the IETF in Dublin, Hein also shown also some results 
that were obtrained using the HOSE model.

Best regards,
Georgios

> Sent: woensdag 27 augustus 2008 10:20
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> A model where the egress measures marks coming from all the 
> ingresses, and makes admission decision based on that.
> 
> Before adding anything about this to the draft, I'd like to 
> understand if this is a genuine practical, understood option 
> (if so, OK), or if it's a theoretical possibility or one not 
> well understood. 
> (there are many things in the latter category that aren't 
> mentioned in the draft.)
> 
> Questions are why this is interesting, why is it better than 
> the models already well-known, are there comparative analysis 
> /simulations?
> 
> [1] every time something is added, overall the document 
> becomes harder to understand, more daunting to read & it 
> looks less like the WG has consensus.
> [2] this is an INFO doc. People are free to invent ways of 
> using the standards pieces other than the architecture draft 
> says, and indeed in ways not yet dreamt of. 
> 
> Phil.
> 
> Behalf Of { Georgios Karagiannis { Sent: 27 August 2008 08:54 
> { To: 'Steven Blake'
> { Cc: [email-masked]
> { > From: Steven Blake [mailto:[email-masked]] { > 
> Sent: woensdag 27 augustus 2008 6:18 { > To: Georgios 
> Karagiannis { > Cc: [email-masked] { > Subject: RE: [PCN] PCN 
> WG last call for { > draft-ietf-pcn-architecture-05.txt
> { >
> { > > > From: Steven Blake [mailto:[email-masked]] { 
> > > > Sent: dinsdag 26 augustus 2008 14:46 { > > > To: 
> Georgios Karagiannis { > > > Cc: [email-masked] { > > > 
> Subject: Re: [PCN] PCN WG last call for { > > > 
> { > > > > 1) Thank you for clarifying the bullet in Setion 
> 3.2 about flow { > > > > termination.
> { > > > >
> { > > > > 2) From what I understand the PCN architecture 
> draft { > > > mentions that PCN { > > > > supports only the 
> trunk (ingress-egress-aggregate) and not the { > > > > HOSE model.
> { > > > > Is the PCN architecture draft excluding solutions 
> that { > support the { > > > > HOSE model? If not, please 
> emphasize in the PCN { > architecture draft { > > > > that 
> "solutions that are based on other types of flow { > > > 
> aggregation than { > > > > the ingress-egress-aggregate 
> method of flow { > aggregation, are not { > > > > excluded 
> { > > I have not seen that the PCN charter excludes other 
> types { > of aggregation.
> { >
> { > > that I am refering to the HOSE model where the traffic 
> sent { > by one or { > > more than one ingresses towards one 
> egress is aggregated at the { > > egress. In this way higgher 
> traffic aggregation can be accomplished { > > than in the 
> situation that the pipe/trunk { > (ingress-egress-aggregate) 
> { > > is used, where the traffic sent by only one ingress in 
> aggegated at { > > the egress.
> { >
> { Georgios: Typically yes, but in this case we refer to 
> bandwidth allocation { in a multipoint-to-point fashion.
> {
> { >
> { >
> { > Regards,
> { >
> { > // Steve
> { >
> {
> {

---

From: <[email-masked]>
Date: Wed, 27 Aug 2008 09:52:31 +0100

I don't recall having read anything before suggesting using the hose
model "backwards" as Georgios suggests but I will admit that I am no
expert in that particular field. 

Whilst the charter doesn't exclude the hose model explicitly it does
seem to be written in such a way as to suggest it is excluded:  
"encoding and transport of (pre-)congestion information between the
egress and the controlling domain ingress" suggests there is a singular
ingress for each decision made at the egress. Other parts of the charter
also seem to indicate this too...

I don't feel we understand the hose model at all well. It seems to have
only been mentioned relatively recently. I think given the maturity of
the rest of the architecture document I don't want to see it held up by
this. I would however be (reasonably) happy to see a sentence along the
following lines:
"This document assumes that all flow admission and termination decisions
are based on the trunk (IEA) model. A future revision to this document
might provide support for the hose model in the configuration where one
egress makes decisions based on information received from many
ingresses.

Toby
____________________________________________________________________
Toby Moncaster, <[email-masked]> Networks Research Centre, BT
B54/70 Adastral Park, Ipswich, IP53RE, UK.  +44 1473 648734 

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: 27 August 2008 09:20
> the models
> Behalf Of

---

From: <[email-masked]>
Date: Wed, 27 Aug 2008 10:31:26 +0100

I thought your emails with steve had revealed that your model was the
exact opposite of the well known hose model?

{ -----Original Message-----
{ From: Georgios Karagiannis [mailto:[email-masked]]
{ Sent: 27 August 2008 09:41
{ To: Eardley,PL,Philip,CXR9 R; [email-masked]
{ Cc: [email-masked]
{ Subject: RE: [PCN] PCN WG last call for
draft-ietf-pcn-architecture-05.txt
{ 
{ Hi Phil
{ 
{ What I explained is the well know HOSE bandwidth management model.
{ During the IETF in Dublin, Hein also shown also some results
{ that were obtrained using the HOSE model.
{ 
{ 
{ Best regards,
{ Georgios
{ 
{ 
{ > -----Original Message-----
{ > From: [email-masked] [mailto:[email-masked]]
{ > Sent: woensdag 27 augustus 2008 10:20
{ > To: [email-masked]; [email-masked]
{ > Cc: [email-masked]
{ > Subject: RE: [PCN] PCN WG last call for
{ > draft-ietf-pcn-architecture-05.txt
{ >
{ > So the question is about adding to the draft:
{ > A model where the egress measures marks coming from all the
{ > ingresses, and makes admission decision based on that.
{ >
{ > Before adding anything about this to the draft, I'd like to
{ > understand if this is a genuine practical, understood option
{ > (if so, OK), or if it's a theoretical possibility or one not
{ > well understood.
{ > (there are many things in the latter category that aren't
{ > mentioned in the draft.)
{ >
{ > Questions are why this is interesting, why is it better than
{ > the models already well-known, are there comparative analysis
{ > /simulations?
{ >
{ > I suppose I've got 2 general issues:
{ > [1] every time something is added, overall the document
{ > becomes harder to understand, more daunting to read & it
{ > looks less like the WG has consensus.
{ > [2] this is an INFO doc. People are free to invent ways of
{ > using the standards pieces other than the architecture draft
{ > says, and indeed in ways not yet dreamt of.
{ >
{ > Phil.
{ >
{ > { -----Original Message-----
{ > { From: [email-masked] [mailto:[email-masked]] On
{ > Behalf Of { Georgios Karagiannis { Sent: 27 August 2008 08:54
{ > { To: 'Steven Blake'
{ > { Cc: [email-masked]
{ > { Subject: Re: [PCN] PCN WG last call for
{ > draft-ietf-pcn-architecture-05.txt
{ > {
{ > { Hi Steven
{ > {
{ > { > -----Original Message-----
{ > { > From: Steven Blake [mailto:[email-masked]] { >
{ > Sent: woensdag 27 augustus 2008 6:18 { > To: Georgios
{ > Karagiannis { > Cc: [email-masked] { > Subject: RE: [PCN] PCN
{ > WG last call for { > draft-ietf-pcn-architecture-05.txt
{ > { >
{ > { > On Tue, 2008-08-26 at 16:11 +0200, Georgios Karagiannis wrote:
{ > { >
{ > { > > Hi Steven
{ > { > >
{ > { > >
{ > { > > Please see in line!
{ > { > >
{ > { > >
{ > { > > > -----Original Message-----
{ > { > > > From: Steven Blake [mailto:[email-masked]] {
{ > > > > Sent: dinsdag 26 augustus 2008 14:46 { > > > To:
{ > Georgios Karagiannis { > > > Cc: [email-masked] { > > >
{ > Subject: Re: [PCN] PCN WG last call for { > > >
{ > draft-ietf-pcn-architecture-05.txt
{ > { > > >
{ > { > > > On Tue, 2008-08-26 at 11:44 +0000, Georgios Karagiannis
wrote:
{ > { > > >
{ > { > > > > Hi Phil, Hi all
{ > { > > > >
{ > { > > > > Here are some  comments on the PCN architecture draft:
{ > { > > > >
{ > { > > > > 1) Thank you for clarifying the bullet in Setion
{ > 3.2 about flow { > > > > termination.
{ > { > > > >
{ > { > > > > 2) From what I understand the PCN architecture
{ > draft { > > > mentions that PCN { > > > > supports only the
{ > trunk (ingress-egress-aggregate) and not the { > > > > HOSE model.
{ > { > > > > Is the PCN architecture draft excluding solutions
{ > that { > support the { > > > > HOSE model? If not, please
{ > emphasize in the PCN { > architecture draft { > > > > that
{ > "solutions that are based on other types of flow { > > >
{ > aggregation than { > > > > the ingress-egress-aggregate
{ > method of flow { > aggregation, are not { > > > > excluded
{ > from the PCN WG activities."
{ > { > > >
{ > { > > > Actually they are, by our charter.
{ > { > >
{ > { > > I have not seen that the PCN charter excludes other
{ > types { > of aggregation.
{ > { >
{ > { > Well, I checked, and you are correct (mea culpa).
{ > { Georgios: No problem
{ > {
{ > { >
{ > { > > Please note
{ > { > > that I am refering to the HOSE model where the traffic
{ > sent { > by one or { > > more than one ingresses towards one
{ > egress is aggregated at the { > > egress. In this way higgher
{ > traffic aggregation can be accomplished { > > than in the
{ > situation that the pipe/trunk { > (ingress-egress-aggregate)
{ > { > > is used, where the traffic sent by only one ingress in
{ > aggegated at { > > the egress.
{ > { >
{ > { > Typically the "hose" model refers to point-to-multipoint
{ > { > traffic flow, not multipoint-to-point.
{ > { Georgios: Typically yes, but in this case we refer to
{ > bandwidth allocation { in a multipoint-to-point fashion.
{ > {
{ > { >
{ > { >
{ > { > Regards,
{ > { >
{ > { > // Steve
{ > { >
{ > {
{ > {
{ > { _______________________________________________
{ > { PCN mailing list
{ > { [email-masked]
{ > { https://www.ietf.org/mailman/listinfo/pcn
{ >
{

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 27 Aug 2008 11:37:37 +0200

Hi Toby

What about the following two sentences:

 "This document assumes that all flow admission and 
 termination decisions are based on the trunk (IEA) model. However, this
document 
 does not exclude a possible extension to the IEA model, denoted as hose
model, 
 where one egress makes decisions based on information received from many
ingresses."

Best regards,
Georgios

> From: [email-masked] [mailto:[email-masked]] 
> Sent: woensdag 27 augustus 2008 10:53
> To: [email-masked]; [email-masked]; 
> [email-masked]
> Cc: [email-masked]
> I don't recall having read anything before suggesting using 
> the hose model "backwards" as Georgios suggests but I will 
> admit that I am no expert in that particular field. 
> 
> Whilst the charter doesn't exclude the hose model explicitly 
> it does seem to be written in such a way as to suggest it is 
> excluded:  
> "encoding and transport of (pre-)congestion information 
> between the egress and the controlling domain ingress" 
> suggests there is a singular ingress for each decision made 
> at the egress. Other parts of the charter also seem to 
> indicate this too...
> 
> I don't feel we understand the hose model at all well. It 
> seems to have only been mentioned relatively recently. I 
> think given the maturity of the rest of the architecture 
> document I don't want to see it held up by this. I would 
> however be (reasonably) happy to see a sentence along the 
> following lines:
> "This document assumes that all flow admission and 
> termination decisions are based on the trunk (IEA) model. A 
> future revision to this document might provide support for 
> the hose model in the configuration where one egress makes 
> decisions based on information received from many ingresses.
> 
> Toby
> Toby Moncaster, <[email-masked]> Networks Research 
> Centre, BT B54/70 Adastral Park, Ipswich, IP53RE, UK.  +44 
> 1473 648734 
> 
> 
> > [email-masked]
> ingresses, 
> understand 
> mentioned in 
> > Questions are why this is interesting, why is it better than the 
> > models already well-known, are there comparative analysis 
> > /simulations?
> > 
> becomes harder 
> using the 
> > { From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > Of { Georgios Karagiannis { Sent: 27 August 2008 08:54 { 
> To: 'Steven 
> > Blake'
> > { Cc: [email-masked]
> > { > From: Steven Blake [mailto:[email-masked]] { > Sent: 
> > woensdag 27 augustus 2008 6:18 { > To: Georgios Karagiannis { > Cc: 
> > [email-masked] { > Subject: RE: [PCN] PCN WG last call for { > 
> > { > > > From: Steven Blake [mailto:[email-masked]] { > > > 
> > Sent: dinsdag 26 augustus 2008 14:46 { > > > To: Georgios 
> Karagiannis 
> > { > > > Cc: [email-masked] { > > > Subject: Re: [PCN] PCN WG 
> last call 
> > for { > > > draft-ietf-pcn-architecture-05.txt
> > { > > >
> draft { > > > 
> > mentions that PCN { > > > > supports only the trunk 
> > (ingress-egress-aggregate) and not the { > > > > HOSE model.
> that { > 
> > support the { > > > > HOSE model? If not, please emphasize 
> in the PCN 
> > { > architecture draft { > > > > that "solutions that are based on 
> > other types of flow { > > > aggregation than { > > > > the 
> > ingress-egress-aggregate method of flow { > aggregation, 
> are not { > > 
> types { > of 
> > aggregation.
> > { > > that I am refering to the HOSE model where the 
> traffic sent { > 
> > by one or { > > more than one ingresses towards one egress is 
> > aggregated at the { > > egress. In this way higgher traffic 
> > aggregation can be accomplished { > > than in the situation 
> that the 
> > pipe/trunk { > (ingress-egress-aggregate) { > > is used, where the 
> > traffic sent by only one ingress in aggegated at { > > the egress.
> > { >
> > { > Typically the "hose" model refers to point-to-multipoint { > 
> > allocation { in a multipoint-to-point fashion.
> > {
> > { >
> > { >
> > { > Regards,
> > { >
> > { > // Steve
> > { >
> > {
> > {

---

From: <[email-masked]>
Date: Wed, 27 Aug 2008 10:49:43 +0100

at the moment I'm against adding any such text. Please see earlier email
for the reasons & how to convince me to change my mind. 

{ -----Original Message-----
{ From: Georgios Karagiannis [mailto:[email-masked]]
{ Sent: 27 August 2008 10:38
{ To: Moncaster,T,Toby,CXR9 R; Eardley,PL,Philip,CXR9 R; slblake@petri-
{ meat.com
{ Cc: [email-masked]
{ Subject: RE: [PCN] PCN WG last call for
draft-ietf-pcn-architecture-05.txt
{ 
{ Hi Toby
{ 
{ What about the following two sentences:
{ 
{  "This document assumes that all flow admission and
{  termination decisions are based on the trunk (IEA) model. However,
this
{ document
{  does not exclude a possible extension to the IEA model, denoted as
hose
{ model,
{  where one egress makes decisions based on information received from
many
{ ingresses."
{ 
{ 
{ Best regards,
{ Georgios
{ 
{ 
{ > -----Original Message-----
{ > From: [email-masked] [mailto:[email-masked]]
{ > Sent: woensdag 27 augustus 2008 10:53
{ > To: [email-masked]; [email-masked];
{ > [email-masked]
{ > Cc: [email-masked]
{ > Subject: RE: [PCN] PCN WG last call for
{ > draft-ietf-pcn-architecture-05.txt
{ >
{ > I don't recall having read anything before suggesting using
{ > the hose model "backwards" as Georgios suggests but I will
{ > admit that I am no expert in that particular field.
{ >
{ > Whilst the charter doesn't exclude the hose model explicitly
{ > it does seem to be written in such a way as to suggest it is
{ > excluded:
{ > "encoding and transport of (pre-)congestion information
{ > between the egress and the controlling domain ingress"
{ > suggests there is a singular ingress for each decision made
{ > at the egress. Other parts of the charter also seem to
{ > indicate this too...
{ >
{ > I don't feel we understand the hose model at all well. It
{ > seems to have only been mentioned relatively recently. I
{ > think given the maturity of the rest of the architecture
{ > document I don't want to see it held up by this. I would
{ > however be (reasonably) happy to see a sentence along the
{ > following lines:
{ > "This document assumes that all flow admission and
{ > termination decisions are based on the trunk (IEA) model. A
{ > future revision to this document might provide support for
{ > the hose model in the configuration where one egress makes
{ > decisions based on information received from many ingresses.
{ >
{ > Toby
{ > ____________________________________________________________________
{ > Toby Moncaster, <[email-masked]> Networks Research
{ > Centre, BT B54/70 Adastral Park, Ipswich, IP53RE, UK.  +44
{ > 1473 648734
{ >
{ >
{ > > -----Original Message-----
{ > > From: [email-masked] [mailto:[email-masked]] On
{ > Behalf Of
{ > > [email-masked]
{ > > Sent: 27 August 2008 09:20
{ > > To: [email-masked]; [email-masked]
{ > > Cc: [email-masked]
{ > > Subject: Re: [PCN] PCN WG last call for
{ > > draft-ietf-pcn-architecture-05.txt
{ > >
{ > > So the question is about adding to the draft:
{ > > A model where the egress measures marks coming from all the
{ > ingresses,
{ > > and makes admission decision based on that.
{ > >
{ > > Before adding anything about this to the draft, I'd like to
{ > understand
{ > > if this is a genuine practical, understood option (if so,
{ > OK), or if
{ > > it's a theoretical possibility or one not well understood.
{ > > (there are many things in the latter category that aren't
{ > mentioned in
{ > > the draft.)
{ > >
{ > > Questions are why this is interesting, why is it better than the
{ > > models already well-known, are there comparative analysis
{ > > /simulations?
{ > >
{ > > I suppose I've got 2 general issues:
{ > > [1] every time something is added, overall the document
{ > becomes harder
{ > > to understand, more daunting to read & it looks less like
{ > the WG has
{ > > consensus.
{ > > [2] this is an INFO doc. People are free to invent ways of
{ > using the
{ > > standards pieces other than the architecture draft says,
{ > and indeed in
{ > > ways not yet dreamt of.
{ > >
{ > > Phil.
{ > >
{ > > { -----Original Message-----
{ > > { From: [email-masked] [mailto:[email-masked]]
{ > On Behalf
{ > > Of { Georgios Karagiannis { Sent: 27 August 2008 08:54 {
{ > To: 'Steven
{ > > Blake'
{ > > { Cc: [email-masked]
{ > > { Subject: Re: [PCN] PCN WG last call for
{ > > draft-ietf-pcn-architecture-05.txt
{ > > {
{ > > { Hi Steven
{ > > {
{ > > { > -----Original Message-----
{ > > { > From: Steven Blake [mailto:[email-masked]] { > Sent:
{ > > woensdag 27 augustus 2008 6:18 { > To: Georgios Karagiannis { >
Cc:
{ > > [email-masked] { > Subject: RE: [PCN] PCN WG last call for { >
{ > > draft-ietf-pcn-architecture-05.txt
{ > > { >
{ > > { > On Tue, 2008-08-26 at 16:11 +0200, Georgios Karagiannis wrote:
{ > > { >
{ > > { > > Hi Steven
{ > > { > >
{ > > { > >
{ > > { > > Please see in line!
{ > > { > >
{ > > { > >
{ > > { > > > -----Original Message-----
{ > > { > > > From: Steven Blake [mailto:[email-masked]] { > > >
{ > > Sent: dinsdag 26 augustus 2008 14:46 { > > > To: Georgios
{ > Karagiannis
{ > > { > > > Cc: [email-masked] { > > > Subject: Re: [PCN] PCN WG
{ > last call
{ > > for { > > > draft-ietf-pcn-architecture-05.txt
{ > > { > > >
{ > > { > > > On Tue, 2008-08-26 at 11:44 +0000, Georgios
{ > Karagiannis wrote:
{ > > { > > >
{ > > { > > > > Hi Phil, Hi all
{ > > { > > > >
{ > > { > > > > Here are some  comments on the PCN architecture draft:
{ > > { > > > >
{ > > { > > > > 1) Thank you for clarifying the bullet in Setion
{ > 3.2 about
{ > > flow { > > > > termination.
{ > > { > > > >
{ > > { > > > > 2) From what I understand the PCN architecture
{ > draft { > > >
{ > > mentions that PCN { > > > > supports only the trunk
{ > > (ingress-egress-aggregate) and not the { > > > > HOSE model.
{ > > { > > > > Is the PCN architecture draft excluding solutions
{ > that { >
{ > > support the { > > > > HOSE model? If not, please emphasize
{ > in the PCN
{ > > { > architecture draft { > > > > that "solutions that are based on
{ > > other types of flow { > > > aggregation than { > > > > the
{ > > ingress-egress-aggregate method of flow { > aggregation,
{ > are not { > >
{ > > > > excluded from the PCN WG activities."
{ > > { > > >
{ > > { > > > Actually they are, by our charter.
{ > > { > >
{ > > { > > I have not seen that the PCN charter excludes other
{ > types { > of
{ > > aggregation.
{ > > { >
{ > > { > Well, I checked, and you are correct (mea culpa).
{ > > { Georgios: No problem
{ > > {
{ > > { >
{ > > { > > Please note
{ > > { > > that I am refering to the HOSE model where the
{ > traffic sent { >
{ > > by one or { > > more than one ingresses towards one egress is
{ > > aggregated at the { > > egress. In this way higgher traffic
{ > > aggregation can be accomplished { > > than in the situation
{ > that the
{ > > pipe/trunk { > (ingress-egress-aggregate) { > > is used, where the
{ > > traffic sent by only one ingress in aggegated at { > > the egress.
{ > > { >
{ > > { > Typically the "hose" model refers to point-to-multipoint { >
{ > > traffic flow, not multipoint-to-point.
{ > > { Georgios: Typically yes, but in this case we refer to bandwidth
{ > > allocation { in a multipoint-to-point fashion.
{ > > {
{ > > { >
{ > > { >
{ > > { > Regards,
{ > > { >
{ > > { > // Steve
{ > > { >
{ > > {
{ > > {
{ > > { _______________________________________________
{ > > { PCN mailing list
{ > > { [email-masked]
{ > > { https://www.ietf.org/mailman/listinfo/pcn
{ > > _______________________________________________
{ > > PCN mailing list
{ > > [email-masked]
{ > > https://www.ietf.org/mailman/listinfo/pcn
{ > >
{ >
{

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 27 Aug 2008 12:37:04 +0200

Hi Phil

HOSE model is defined some 20 years ago, please see e.g the following
article:

N. G. Duffield, P. Goyal and A. Greenberg, "A Flexible Model
for Resource Management in Virtual Private Networks", in:
Proc. of ACM SIGCOMM, 1999.

In the above article I found the following definition:

"A hose is characterized by the aggregate traffic
to and from one endpoint in the VPN to the set of other
endpoints in the VPN"

Thus the definition refers to aggregated traffic to and from one edge to and
from all other endpoints.

In our case we refer only to the aggregated traffic from other endpoints to
one endpoint.

Thus what we use is in line with the definition of the HOSE model.

Best regards,
Georgios

> Sent: woensdag 27 augustus 2008 11:31
> I thought your emails with steve had revealed that your model 
> was the exact opposite of the well known hose model?
> 
> 
> { Sent: 27 August 2008 09:41 { To: Eardley,PL,Philip,CXR9 R; 
> [email-masked] { Cc: [email-masked] { Subject: RE: 
> [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt
> {
> { Hi Phil
> {
> { During the IETF in Dublin, Hein also shown also some 
> results { that were obtrained using the HOSE model.
> {
> {
> { Best regards,
> { Georgios
> {
> {
> { > From: [email-masked] 
> [mailto:[email-masked]] { > Sent: woensdag 27 augustus 
> 2008 10:20 { > To: [email-masked]; 
> [email-masked] { > Cc: [email-masked] { > Subject: RE: 
> [PCN] PCN WG last call for { > draft-ietf-pcn-architecture-05.txt
> { >
> { > A model where the egress measures marks coming from all 
> the { > ingresses, and makes admission decision based on that.
> { >
> { > Before adding anything about this to the draft, I'd like 
> to { > understand if this is a genuine practical, understood 
> option { > (if so, OK), or if it's a theoretical possibility 
> or one not { > well understood.
> { > mentioned in the draft.) { > { > Questions are why this 
> is interesting, why is it better than { > the models already 
> well-known, are there comparative analysis { > /simulations?
> { >
> { > [1] every time something is added, overall the document { 
> becomes harder to understand, more daunting to read & it { > > looks less
like the WG has consensus.
> { > [2] this is an INFO doc. People are free to invent ways 
> of { > using the standards pieces other than the architecture 
> draft { > says, and indeed in ways not yet dreamt of.
> { >
> { > Phil.
> { >
> { > { From: [email-masked] 
> [mailto:[email-masked]] On { > Behalf Of { Georgios 
> Karagiannis { Sent: 27 August 2008 08:54 { > { To: 'Steven Blake'
> { > { Cc: [email-masked]
> { > { Subject: Re: [PCN] PCN WG last call for { > 
> { > { > From: Steven Blake [mailto:[email-masked]] { 
> > { > Sent: woensdag 27 augustus 2008 6:18 { > To: Georgios { 
> Karagiannis { > Cc: [email-masked] { > Subject: RE: [PCN] PCN > { > WG last
call for { > draft-ietf-pcn-architecture-05.txt
> { > { > > > From: Steven Blake 
> [mailto:[email-masked]] { { > > > > Sent: dinsdag 26 
> augustus 2008 14:46 { > > > To:
> { > Georgios Karagiannis { > > > Cc: [email-masked] { > > > { > 
> Subject: Re: [PCN] PCN WG last call for { > > > { > 
> { > { > > > > 1) Thank you for clarifying the bullet in 
> Setion { > 3.2 about flow { > > > > termination.
> { > { > > > >
> { > draft { > > > mentions that PCN { > > > > supports only 
> the { > trunk (ingress-egress-aggregate) and not the { > > > 
> > HOSE model.
> { > { > > > > Is the PCN architecture draft excluding 
> solutions { > that { > support the { > > > > HOSE model? If 
> not, please { > emphasize in the PCN { > architecture draft { 
> > > > that { > "solutions that are based on other types of > flow { > > >
{ > aggregation than { > > > > the 
> ingress-egress-aggregate { > method of flow { > aggregation, 
> are not { > > > > excluded { > from the PCN WG activities."
> { > { > > >
> { > { > > that I am refering to the HOSE model where the 
> traffic { > sent { > by one or { > > more than one ingresses 
> towards one { > egress is aggregated at the { > > egress. In 
> this way higgher { > traffic aggregation can be accomplished 
> { > > than in the { > situation that the pipe/trunk { > 
> (ingress-egress-aggregate) { > { > > is used, where the 
> traffic sent by only one ingress in { > aggegated at { > > the egress.
> { > { >
> { > { > Typically the "hose" model refers to 
> point-to-multipoint { > { > traffic flow, not multipoint-to-point.
> { > { Georgios: Typically yes, but in this case we refer to {

---

From: <[email-masked]>
Date: Wed, 27 Aug 2008 12:34:52 +0100

I note that the Duffield et al definition below is different from what
your talking about, since their definition includes traffic in both
directions, whilst yours is a one way definition. I think other people,
with a DiffServ architecture background, would interpret it as traffic
from one ingress going to any egress. So that's 3 possibilities.

In any case, this is really a side issue, compared with my main points
/questions in earlier email.

{ -----Original Message-----
{ From: Georgios Karagiannis [mailto:[email-masked]]
{ Sent: 27 August 2008 11:37
{ To: Eardley,PL,Philip,CXR9 R; [email-masked]
{ Cc: [email-masked]
{ Subject: RE: [PCN] PCN WG last call for
draft-ietf-pcn-architecture-05.txt
{ 
{ Hi Phil
{ 
{ HOSE model is defined some 20 years ago, please see e.g the following
{ article:
{ 
{ N. G. Duffield, P. Goyal and A. Greenberg, "A Flexible Model
{ for Resource Management in Virtual Private Networks", in:
{ Proc. of ACM SIGCOMM, 1999.
{ 
{ In the above article I found the following definition:
{ 
{ "A hose is characterized by the aggregate traffic
{ to and from one endpoint in the VPN to the set of other
{ endpoints in the VPN"
{ 
{ Thus the definition refers to aggregated traffic to and from one edge
to
{ and
{ from all other endpoints.
{ 
{ 
{ In our case we refer only to the aggregated traffic from other
endpoints
{ to
{ one endpoint.
{ 
{ Thus what we use is in line with the definition of the HOSE model.
{ 
{ Best regards,
{ Georgios
{ 
{ 
{ 
{ 
{ > -----Original Message-----
{ > From: [email-masked] [mailto:[email-masked]]
{ > Sent: woensdag 27 augustus 2008 11:31
{ > To: [email-masked]; [email-masked]
{ > Cc: [email-masked]
{ > Subject: RE: [PCN] PCN WG last call for
{ > draft-ietf-pcn-architecture-05.txt
{ >
{ > I thought your emails with steve had revealed that your model
{ > was the exact opposite of the well known hose model?
{ >
{ >
{ > { -----Original Message-----
{ > { From: Georgios Karagiannis [mailto:[email-masked]]
{ > { Sent: 27 August 2008 09:41 { To: Eardley,PL,Philip,CXR9 R;
{ > [email-masked] { Cc: [email-masked] { Subject: RE:
{ > [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt
{ > {
{ > { Hi Phil
{ > {
{ > { What I explained is the well know HOSE bandwidth management model.
{ > { During the IETF in Dublin, Hein also shown also some
{ > results { that were obtrained using the HOSE model.
{ > {
{ > {
{ > { Best regards,
{ > { Georgios
{ > {
{ > {
{ > { > -----Original Message-----
{ > { > From: [email-masked]
{ > [mailto:[email-masked]] { > Sent: woensdag 27 augustus
{ > 2008 10:20 { > To: [email-masked];
{ > [email-masked] { > Cc: [email-masked] { > Subject: RE:
{ > [PCN] PCN WG last call for { > draft-ietf-pcn-architecture-05.txt
{ > { >
{ > { > So the question is about adding to the draft:
{ > { > A model where the egress measures marks coming from all
{ > the { > ingresses, and makes admission decision based on that.
{ > { >
{ > { > Before adding anything about this to the draft, I'd like
{ > to { > understand if this is a genuine practical, understood
{ > option { > (if so, OK), or if it's a theoretical possibility
{ > or one not { > well understood.
{ > { > (there are many things in the latter category that aren't
{ > { > mentioned in the draft.) { > { > Questions are why this
{ > is interesting, why is it better than { > the models already
{ > well-known, are there comparative analysis { > /simulations?
{ > { >
{ > { > I suppose I've got 2 general issues:
{ > { > [1] every time something is added, overall the document {
{ > becomes harder to understand, more daunting to read & it { > > looks
{ less
{ like the WG has consensus.
{ > { > [2] this is an INFO doc. People are free to invent ways
{ > of { > using the standards pieces other than the architecture
{ > draft { > says, and indeed in ways not yet dreamt of.
{ > { >
{ > { > Phil.
{ > { >
{ > { > { -----Original Message-----
{ > { > { From: [email-masked]
{ > [mailto:[email-masked]] On { > Behalf Of { Georgios
{ > Karagiannis { Sent: 27 August 2008 08:54 { > { To: 'Steven Blake'
{ > { > { Cc: [email-masked]
{ > { > { Subject: Re: [PCN] PCN WG last call for { >
{ > draft-ietf-pcn-architecture-05.txt
{ > { > {
{ > { > { Hi Steven
{ > { > {
{ > { > { > -----Original Message-----
{ > { > { > From: Steven Blake [mailto:[email-masked]] {
{ > > { > Sent: woensdag 27 augustus 2008 6:18 { > To: Georgios {
{ > Karagiannis { > Cc: [email-masked] { > Subject: RE: [PCN] PCN > { > WG
{ last
{ call for { > draft-ietf-pcn-architecture-05.txt
{ > { > { >
{ > { > { > On Tue, 2008-08-26 at 16:11 +0200, Georgios Karagiannis
wrote:
{ > { > { >
{ > { > { > > Hi Steven
{ > { > { > >
{ > { > { > >
{ > { > { > > Please see in line!
{ > { > { > >
{ > { > { > >
{ > { > { > > > -----Original Message-----
{ > { > { > > > From: Steven Blake
{ > [mailto:[email-masked]] { { > > > > Sent: dinsdag 26
{ > augustus 2008 14:46 { > > > To:
{ > { > Georgios Karagiannis { > > > Cc: [email-masked] { > > > { >
{ > Subject: Re: [PCN] PCN WG last call for { > > > { >
{ > draft-ietf-pcn-architecture-05.txt
{ > { > { > > >
{ > { > { > > > On Tue, 2008-08-26 at 11:44 +0000, Georgios Karagiannis
{ > wrote:
{ > { > { > > >
{ > { > { > > > > Hi Phil, Hi all
{ > { > { > > > >
{ > { > { > > > > Here are some  comments on the PCN architecture draft:
{ > { > { > > > >
{ > { > { > > > > 1) Thank you for clarifying the bullet in
{ > Setion { > 3.2 about flow { > > > > termination.
{ > { > { > > > >
{ > { > { > > > > 2) From what I understand the PCN architecture
{ > { > draft { > > > mentions that PCN { > > > > supports only
{ > the { > trunk (ingress-egress-aggregate) and not the { > > >
{ > > HOSE model.
{ > { > { > > > > Is the PCN architecture draft excluding
{ > solutions { > that { > support the { > > > > HOSE model? If
{ > not, please { > emphasize in the PCN { > architecture draft {
{ > > > > that { > "solutions that are based on other types of > flow {
{ >
{ { > aggregation than { > > > > the
{ > ingress-egress-aggregate { > method of flow { > aggregation,
{ > are not { > > > > excluded { > from the PCN WG activities."
{ > { > { > > >
{ > { > { > > > Actually they are, by our charter.
{ > { > { > >
{ > { > { > > I have not seen that the PCN charter excludes other
{ > { > types { > of aggregation.
{ > { > { >
{ > { > { > Well, I checked, and you are correct (mea culpa).
{ > { > { Georgios: No problem
{ > { > {
{ > { > { >
{ > { > { > > Please note
{ > { > { > > that I am refering to the HOSE model where the
{ > traffic { > sent { > by one or { > > more than one ingresses
{ > towards one { > egress is aggregated at the { > > egress. In
{ > this way higgher { > traffic aggregation can be accomplished
{ > { > > than in the { > situation that the pipe/trunk { >
{ > (ingress-egress-aggregate) { > { > > is used, where the
{ > traffic sent by only one ingress in { > aggegated at { > > the
egress.
{ > { > { >
{ > { > { > Typically the "hose" model refers to
{ > point-to-multipoint { > { > traffic flow, not multipoint-to-point.
{ > { > { Georgios: Typically yes, but in this case we refer to {
{ > bandwidth allocation { in a multipoint-to-point fashion.
{ > { > {
{ > { > { >
{ > { > { >
{ > { > { > Regards,
{ > { > { >
{ > { > { > // Steve
{ > { > { >
{ > { > {
{ > { > {
{ > { > { _______________________________________________
{ > { > { PCN mailing list
{ > { > { [email-masked]
{ > { > { https://www.ietf.org/mailman/listinfo/pcn
{ > { >
{ > {
{ >
{

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 27 Aug 2008 13:55:52 +0200

Hi Phil

Assuming that ingresses can only send data traffic and egresses can receive
data traffic,
a HOSE model that is used in the PCN domain between ingress nodes and egress
edge nodes, 
is refering to aggregates between ingress and egress edge nodes, where
ingresses are 
sending traffic and egresses are receiving data traffic.

Thus the HOSE aggregation model used in PCN is a HOSE aggregation model 
used between ingress and egress nodes.

Best regards,
Georgios

> Sent: woensdag 27 augustus 2008 13:35
> I note that the Duffield et al definition below is different 
> from what your talking about, since their definition includes 
> traffic in both directions, whilst yours is a one way 
> definition. I think other people, with a DiffServ 
> architecture background, would interpret it as traffic from 
> one ingress going to any egress. So that's 3 possibilities.
> 
> In any case, this is really a side issue, compared with my 
> main points /questions in earlier email.
> 
> { Sent: 27 August 2008 11:37 { To: Eardley,PL,Philip,CXR9 R; 
> { HOSE model is defined some 20 years ago, please see e.g the 
> following { article:
> {
> { N. G. Duffield, P. Goyal and A. Greenberg, "A Flexible 
> Model { for Resource Management in Virtual Private Networks", in:
> { "A hose is characterized by the aggregate traffic { to and 
> from one endpoint in the VPN to the set of other { endpoints 
> in the VPN"
> {
> { Thus the definition refers to aggregated traffic to and 
> from one edge to { and { from all other endpoints.
> {
> {
> { In our case we refer only to the aggregated traffic from 
> other endpoints { to { one endpoint.
> {
> 2008 11:31 { > To: [email-masked]; 
> { > I thought your emails with steve had revealed that your 
> model { > was the exact opposite of the well known hose model?
> { >
> { >
> { > { From: Georgios Karagiannis 
> [mailto:[email-masked]] { > { Sent: 27 August 2008 
> 09:41 { To: Eardley,PL,Philip,CXR9 R; { > 
> { > { During the IETF in Dublin, Hein also shown also some { 
> { > [mailto:[email-masked]] { > Sent: woensdag 27 
> augustus { > 2008 10:20 { > To: [email-masked]; { > 
> { > { > A model where the egress measures marks coming from 
> all { > the { > ingresses, and makes admission decision based on that.
> { > { >
> { > { > Before adding anything about this to the draft, I'd 
> like { > to { > understand if this is a genuine practical, 
> understood { > option { > (if so, OK), or if it's a 
> theoretical possibility { > or one not { > well understood.
> { > { > (there are many things in the latter category that 
> aren't { > { > mentioned in the draft.) { > { > Questions are 
> why this { > is interesting, why is it better than { > the 
> models already { > well-known, are there comparative analysis 
> { > /simulations?
> { > { >
> { > { > [1] every time something is added, overall the 
> document { { > becomes harder to understand, more daunting to 
> read & it { > > looks { less { like the WG has consensus.
> { > { > [2] this is an INFO doc. People are free to invent 
> ways { > of { > using the standards pieces other than the 
> architecture { > draft { > says, and indeed in ways not yet dreamt of.
> { > { >
> { > { > Phil.
> { > { >
> { > { > { Subject: Re: [PCN] PCN WG last call for { > { > 
> { > { > { > From: Steven Blake 
> [mailto:[email-masked]] { { > > { > Sent: woensdag 27 
> augustus 2008 6:18 { > To: Georgios { { > Karagiannis { > Cc: 
> [email-masked] { > Subject: RE: [PCN] PCN > { > WG { last { 
> { > { > { > > > -----Original Message----- { > { > { > > > 
> From: Steven Blake { > [mailto:[email-masked]] { { > 
> > > > Sent: dinsdag 26 { > augustus 2008 14:46 { > > > To:
> { > { > Georgios Karagiannis { > > > Cc: [email-masked] { > > > 
> { > { > Subject: Re: [PCN] PCN WG last call for { > > > { > { 
> { > { > { > > > On Tue, 2008-08-26 at 11:44 +0000, Georgios 
> Karagiannis { > wrote:
> { > { > { > > >
> { > { > { > > > > 1) Thank you for clarifying the bullet in { 
> { > { > { > > > > 2) From what I understand the PCN 
> architecture { > { > draft { > > > mentions that PCN { > > > 
> > supports only { > the { > trunk (ingress-egress-aggregate) 
> and not the { > > > { > > HOSE model.
> { > { > { > > > > Is the PCN architecture draft excluding { > 
> solutions { > that { > support the { > > > > HOSE model? If { 
> not, please { > emphasize in the PCN { > architecture draft { > { > > > >
that { > "solutions that are based on other types 
> of > flow {
> { > ingress-egress-aggregate { > method of flow { > 
> aggregation, { > are not { > > > > excluded { > from the PCN 
> WG activities."
> { > { > { > > >
> { > { > { > > I have not seen that the PCN charter excludes 
> other { > { > types { > of aggregation.
> { > { > { >
> { > traffic { > sent { > by one or { > > more than one 
> ingresses { > towards one { > egress is aggregated at the { > 
> > egress. In { > this way higgher { > traffic aggregation can 
> be accomplished { > { > > than in the { > situation that the 
> pipe/trunk { > { > (ingress-egress-aggregate) { > { > > is 
> used, where the { > traffic sent by only one ingress in { > 
> { > { > { > Typically the "hose" model refers to { > 
> { > { > { Georgios: Typically yes, but in this case we refer 
> to { { > bandwidth allocation { in a multipoint-to-point fashion.
> { > { > {
> { > { > { >
> { > { > { >
> { > { > { > Regards,
> { > { > { >
> { > { > { > // Steve
> { > { > { >
> { > { > {
> { > { > {

---

From: <[email-masked]>
Date: Wed, 27 Aug 2008 13:03:02 +0100

You appear to be saying all 3 definitions are the same. I think they're
all different.

Let's call the gateway nodes A, B, C, D ,E and F.

Duffield: hose at A is all traffic to b,c,d,e,f and all traffic from
b,c,d,e,f

DiffServ: hose at A is all traffic to b,c,d,e,f

Georgios: hose at A is all traffic from b,c,d,e,f

{ -----Original Message-----
{ From: Georgios Karagiannis [mailto:[email-masked]]
{ Sent: 27 August 2008 12:56
{ To: Eardley,PL,Philip,CXR9 R; [email-masked]
{ Cc: [email-masked]
{ Subject: RE: [PCN] PCN WG last call for
draft-ietf-pcn-architecture-05.txt
{ 
{ Hi Phil
{ 
{ Assuming that ingresses can only send data traffic and egresses can
{ receive
{ data traffic,
{ a HOSE model that is used in the PCN domain between ingress nodes and
{ egress
{ edge nodes,
{ is refering to aggregates between ingress and egress edge nodes, where
{ ingresses are
{ sending traffic and egresses are receiving data traffic.
{ 
{ Thus the HOSE aggregation model used in PCN is a HOSE aggregation
model
{ used between ingress and egress nodes.
{ 
{ 
{ Best regards,
{ Georgios
{ 
{ > -----Original Message-----
{ > From: [email-masked] [mailto:[email-masked]]
{ > Sent: woensdag 27 augustus 2008 13:35
{ > To: [email-masked]; [email-masked]
{ > Cc: [email-masked]
{ > Subject: RE: [PCN] PCN WG last call for
{ > draft-ietf-pcn-architecture-05.txt
{ >
{ > I note that the Duffield et al definition below is different
{ > from what your talking about, since their definition includes
{ > traffic in both directions, whilst yours is a one way
{ > definition. I think other people, with a DiffServ
{ > architecture background, would interpret it as traffic from
{ > one ingress going to any egress. So that's 3 possibilities.
{ >
{ > In any case, this is really a side issue, compared with my
{ > main points /questions in earlier email.
{ >
{ > { -----Original Message-----
{ > { From: Georgios Karagiannis [mailto:[email-masked]]
{ > { Sent: 27 August 2008 11:37 { To: Eardley,PL,Philip,CXR9 R;
{ > [email-masked] { Cc: [email-masked] { Subject: RE:
{ > [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt
{ > {
{ > { Hi Phil
{ > {
{ > { HOSE model is defined some 20 years ago, please see e.g the
{ > following { article:
{ > {
{ > { N. G. Duffield, P. Goyal and A. Greenberg, "A Flexible
{ > Model { for Resource Management in Virtual Private Networks", in:
{ > { Proc. of ACM SIGCOMM, 1999.
{ > {
{ > { In the above article I found the following definition:
{ > {
{ > { "A hose is characterized by the aggregate traffic { to and
{ > from one endpoint in the VPN to the set of other { endpoints
{ > in the VPN"
{ > {
{ > { Thus the definition refers to aggregated traffic to and
{ > from one edge to { and { from all other endpoints.
{ > {
{ > {
{ > { In our case we refer only to the aggregated traffic from
{ > other endpoints { to { one endpoint.
{ > {
{ > { Thus what we use is in line with the definition of the HOSE model.
{ > {
{ > { Best regards,
{ > { Georgios
{ > {
{ > {
{ > {
{ > {
{ > { > -----Original Message-----
{ > { > From: [email-masked]
{ > [mailto:[email-masked]] { > Sent: woensdag 27 augustus
{ > 2008 11:31 { > To: [email-masked];
{ > [email-masked] { > Cc: [email-masked] { > Subject: RE:
{ > [PCN] PCN WG last call for { > draft-ietf-pcn-architecture-05.txt
{ > { >
{ > { > I thought your emails with steve had revealed that your
{ > model { > was the exact opposite of the well known hose model?
{ > { >
{ > { >
{ > { > { -----Original Message-----
{ > { > { From: Georgios Karagiannis
{ > [mailto:[email-masked]] { > { Sent: 27 August 2008
{ > 09:41 { To: Eardley,PL,Philip,CXR9 R; { >
{ > [email-masked] { Cc: [email-masked] { Subject: RE:
{ > { > [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt
{ > { > {
{ > { > { Hi Phil
{ > { > {
{ > { > { What I explained is the well know HOSE bandwidth
{ > management model.
{ > { > { During the IETF in Dublin, Hein also shown also some {
{ > > results { that were obtrained using the HOSE model.
{ > { > {
{ > { > {
{ > { > { Best regards,
{ > { > { Georgios
{ > { > {
{ > { > {
{ > { > { > -----Original Message-----
{ > { > { > From: [email-masked]
{ > { > [mailto:[email-masked]] { > Sent: woensdag 27
{ > augustus { > 2008 10:20 { > To: [email-masked]; { >
{ > [email-masked] { > Cc: [email-masked] { > Subject: RE:
{ > { > [PCN] PCN WG last call for { >
draft-ietf-pcn-architecture-05.txt
{ > { > { >
{ > { > { > So the question is about adding to the draft:
{ > { > { > A model where the egress measures marks coming from
{ > all { > the { > ingresses, and makes admission decision based on
that.
{ > { > { >
{ > { > { > Before adding anything about this to the draft, I'd
{ > like { > to { > understand if this is a genuine practical,
{ > understood { > option { > (if so, OK), or if it's a
{ > theoretical possibility { > or one not { > well understood.
{ > { > { > (there are many things in the latter category that
{ > aren't { > { > mentioned in the draft.) { > { > Questions are
{ > why this { > is interesting, why is it better than { > the
{ > models already { > well-known, are there comparative analysis
{ > { > /simulations?
{ > { > { >
{ > { > { > I suppose I've got 2 general issues:
{ > { > { > [1] every time something is added, overall the
{ > document { { > becomes harder to understand, more daunting to
{ > read & it { > > looks { less { like the WG has consensus.
{ > { > { > [2] this is an INFO doc. People are free to invent
{ > ways { > of { > using the standards pieces other than the
{ > architecture { > draft { > says, and indeed in ways not yet dreamt
of.
{ > { > { >
{ > { > { > Phil.
{ > { > { >
{ > { > { > { -----Original Message-----
{ > { > { > { From: [email-masked]
{ > { > [mailto:[email-masked]] On { > Behalf Of { Georgios
{ > { > Karagiannis { Sent: 27 August 2008 08:54 { > { To: 'Steven
Blake'
{ > { > { > { Cc: [email-masked]
{ > { > { > { Subject: Re: [PCN] PCN WG last call for { > { >
{ > draft-ietf-pcn-architecture-05.txt
{ > { > { > {
{ > { > { > { Hi Steven
{ > { > { > {
{ > { > { > { > -----Original Message-----
{ > { > { > { > From: Steven Blake
{ > [mailto:[email-masked]] { { > > { > Sent: woensdag 27
{ > augustus 2008 6:18 { > To: Georgios { { > Karagiannis { > Cc:
{ > [email-masked] { > Subject: RE: [PCN] PCN > { > WG { last {
{ > call for { > draft-ietf-pcn-architecture-05.txt
{ > { > { > { >
{ > { > { > { > On Tue, 2008-08-26 at 16:11 +0200, Georgios Karagiannis
{ > wrote:
{ > { > { > { >
{ > { > { > { > > Hi Steven
{ > { > { > { > >
{ > { > { > { > >
{ > { > { > { > > Please see in line!
{ > { > { > { > >
{ > { > { > { > >
{ > { > { > { > > > -----Original Message----- { > { > { > > >
{ > From: Steven Blake { > [mailto:[email-masked]] { { >
{ > > > > Sent: dinsdag 26 { > augustus 2008 14:46 { > > > To:
{ > { > { > Georgios Karagiannis { > > > Cc: [email-masked] { > > >
{ > { > { > Subject: Re: [PCN] PCN WG last call for { > > > { > {
{ > draft-ietf-pcn-architecture-05.txt
{ > { > { > { > > >
{ > { > { > { > > > On Tue, 2008-08-26 at 11:44 +0000, Georgios
{ > Karagiannis { > wrote:
{ > { > { > { > > >
{ > { > { > { > > > > Hi Phil, Hi all
{ > { > { > { > > > >
{ > { > { > { > > > > Here are some  comments on the PCN
{ > architecture draft:
{ > { > { > { > > > >
{ > { > { > { > > > > 1) Thank you for clarifying the bullet in {
{ > Setion { > 3.2 about flow { > > > > termination.
{ > { > { > { > > > >
{ > { > { > { > > > > 2) From what I understand the PCN
{ > architecture { > { > draft { > > > mentions that PCN { > > >
{ > > supports only { > the { > trunk (ingress-egress-aggregate)
{ > and not the { > > > { > > HOSE model.
{ > { > { > { > > > > Is the PCN architecture draft excluding { >
{ > solutions { > that { > support the { > > > > HOSE model? If {
{ > not, please { > emphasize in the PCN { > architecture draft { > { >
{ >
{ that { > "solutions that are based on other types
{ > of > flow {
{ > > >
{ > { >
{ > { { > aggregation than { > > > > the
{ > { > ingress-egress-aggregate { > method of flow { >
{ > aggregation, { > are not { > > > > excluded { > from the PCN
{ > WG activities."
{ > { > { > { > > >
{ > { > { > { > > > Actually they are, by our charter.
{ > { > { > { > >
{ > { > { > { > > I have not seen that the PCN charter excludes
{ > other { > { > types { > of aggregation.
{ > { > { > { >
{ > { > { > { > Well, I checked, and you are correct (mea culpa).
{ > { > { > { Georgios: No problem
{ > { > { > {
{ > { > { > { >
{ > { > { > { > > Please note
{ > { > { > { > > that I am refering to the HOSE model where the
{ > { > traffic { > sent { > by one or { > > more than one
{ > ingresses { > towards one { > egress is aggregated at the { >
{ > > egress. In { > this way higgher { > traffic aggregation can
{ > be accomplished { > { > > than in the { > situation that the
{ > pipe/trunk { > { > (ingress-egress-aggregate) { > { > > is
{ > used, where the { > traffic sent by only one ingress in { >
{ > aggegated at { > > the egress.
{ > { > { > { >
{ > { > { > { > Typically the "hose" model refers to { >
{ > point-to-multipoint { > { > traffic flow, not multipoint-to-point.
{ > { > { > { Georgios: Typically yes, but in this case we refer
{ > to { { > bandwidth allocation { in a multipoint-to-point fashion.
{ > { > { > {
{ > { > { > { >
{ > { > { > { >
{ > { > { > { > Regards,
{ > { > { > { >
{ > { > { > { > // Steve
{ > { > { > { >
{ > { > { > {
{ > { > { > {
{ > { > { > { _______________________________________________
{ > { > { > { PCN mailing list
{ > { > { > { [email-masked]
{ > { > { > { https://www.ietf.org/mailman/listinfo/pcn
{ > { > { >
{ > { > {
{ > { >
{ > {
{ >
{

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 27 Aug 2008 14:39:51 +0200

Hi Phil

Your explanations are right, but regarding the explanation over 
Diffserv, please note that this is only one of the possible views.

In a HOSE model two aggregated bandwidth specifications per node could be
used:

Incomning aggregated bandwdith: associated with the incoming traffic from
all other nodes 
This is the HOSE model view that I was refereing to.

Outgoing aggregated bandwdith: the amount of the aggregated traffic that the
node can send towards all other nodes.
This is the version that you were referring as Diffserv hose model.

The Duffield Hose model specification uses both aggregated bandwidth 
specifications listed above.

Best regards,
Georgios

> Sent: woensdag 27 augustus 2008 14:03
> You appear to be saying all 3 definitions are the same. I 
> think they're all different.
> 
> Duffield: hose at A is all traffic to b,c,d,e,f and all 
> traffic from b,c,d,e,f
> 
> { Sent: 27 August 2008 12:56 { To: Eardley,PL,Philip,CXR9 R; 
> { Assuming that ingresses can only send data traffic and 
> egresses can { receive { data traffic, { a HOSE model that is 
> used in the PCN domain between ingress nodes and { egress { 
> edge nodes, { is refering to aggregates between ingress and 
> egress edge nodes, where { ingresses are { sending traffic 
> and egresses are receiving data traffic.
> {
> { Thus the HOSE aggregation model used in PCN is a HOSE 
> aggregation model { used between ingress and egress nodes.
> {
> {
> { Best regards,
> { Georgios
> {
> 2008 13:35 { > To: [email-masked]; 
> { > I note that the Duffield et al definition below is 
> different { > from what your talking about, since their 
> definition includes { > traffic in both directions, whilst 
> yours is a one way { > definition. I think other people, with 
> a DiffServ { > architecture background, would interpret it as 
> traffic from { > one ingress going to any egress. So that's 3 
> possibilities.
> { >
> { > In any case, this is really a side issue, compared with 
> my { > main points /questions in earlier email.
> { >
> 11:37 { To: Eardley,PL,Philip,CXR9 R; { > 
> { > { HOSE model is defined some 20 years ago, please see e.g 
> the { > following { article:
> { > {
> { > { "A hose is characterized by the aggregate traffic { to 
> and { > from one endpoint in the VPN to the set of other { 
> endpoints { > in the VPN"
> { > {
> { > { In our case we refer only to the aggregated traffic 
> from { > other endpoints { to { one endpoint.
> { > {
> augustus { > 2008 11:31 { > To: [email-masked]; { > 
> { > { > I thought your emails with steve had revealed that 
> your { > model { > was the exact opposite of the well known 
> hose model?
> { > { >
> { > { >
> { > [mailto:[email-masked]] { > { Sent: 27 August 
> 2008 { > 09:41 { To: Eardley,PL,Philip,CXR9 R; { > { > 
> { > { > { What I explained is the well know HOSE bandwidth { 
> > management model.
> { > { > { During the IETF in Dublin, Hein also shown also 
> some { { > > results { that were obtrained using the HOSE model.
> { > { > {
> { > { > {
> { > { > { Best regards,
> { > { > { Georgios
> { > { > {
> { > { > {
> { > augustus { > 2008 10:20 { > To: [email-masked]; { 
> { > [email-masked] { > Cc: [email-masked] { > Subject: > RE:
> { > { > { > A model where the egress measures marks coming 
> from { > all { > the { > ingresses, and makes admission 
> decision based on that.
> { > { > { >
> { > { > { > Before adding anything about this to the draft, 
> I'd { > like { > to { > understand if this is a genuine 
> practical, { > understood { > option { > (if so, OK), or if 
> it's a { > theoretical possibility { > or one not { > well understood.
> { > { > { > (there are many things in the latter category 
> that { > aren't { > { > mentioned in the draft.) { > { > 
> Questions are { > why this { > is interesting, why is it 
> better than { > the { > models already { > well-known, are 
> there comparative analysis { > { > /simulations?
> { > { > { >
> { > { > { > [1] every time something is added, overall the { 
> > document { { > becomes harder to understand, more daunting 
> to { > read & it { > > looks { less { like the WG has consensus.
> { > { > { > [2] this is an INFO doc. People are free to 
> invent { > ways { > of { > using the standards pieces other 
> than the { > architecture { > draft { > says, and indeed in 
> ways not yet dreamt of.
> { > { > { >
> { > { > { > Phil.
> { > { > { >
> { > { > { > { -----Original Message----- { > { > { > { From: 
> [email-masked] { > { > [mailto:[email-masked]] On 
> { > Behalf Of { Georgios { > { > Karagiannis { Sent: 27 
> August 2008 08:54 { > { To: 'Steven Blake'
> { > { > { > { > -----Original Message----- { > { > { > { > 
> > { > Sent: woensdag 27 { > augustus 2008 6:18 { > To: 
> Georgios { { > Karagiannis { > Cc:
> { > { > { > { > On Tue, 2008-08-26 at 16:11 +0200, Georgios 
> Karagiannis { > wrote:
> { > { > { > { >
> { > { > { > { > > > -----Original Message----- { > { > { > > 
> > { > From: Steven Blake { > [mailto:[email-masked]] 
> { { > { > > > > Sent: dinsdag 26 { > augustus 2008 14:46 { > > > To:
> { > { > { > Georgios Karagiannis { > > > Cc: [email-masked] { > 
> > > { > { > { > Subject: Re: [PCN] PCN WG last call for { > > 
> > { > { { > draft-ietf-pcn-architecture-05.txt
> { > { > { > { > > >
> { > { > { > { > > > On Tue, 2008-08-26 at 11:44 +0000, 
> Georgios { > Karagiannis { > wrote:
> { > { > { > { > > >
> { > { > { > { > > > > Here are some  comments on the PCN { > 
> architecture draft:
> { > { > { > { > > > >
> { > { > { > { > > > > 1) Thank you for clarifying the bullet 
> in { { > Setion { > 3.2 about flow { > > > > termination.
> { > { > { > { > > > >
> { > { > { > { > > > > 2) From what I understand the PCN { > 
> { > > supports only { > the { > trunk 
> (ingress-egress-aggregate) { > and not the { > > > { > > HOSE model.
> { > { > { > { > > > > Is the PCN architecture draft excluding 
> { > { > solutions { > that { > support the { > > > > HOSE 
> model? If { { > not, please { > emphasize in the PCN { > 
> architecture draft { > { >
> > >
> { >
> { that { > "solutions that are based on other types { > of > 
> flow { { > > > { > { > { > { { > aggregation than { > > > > 
> the { > { > ingress-egress-aggregate { > method of flow { > { 
> aggregation, { > are not { > > > > excluded { > from the PCN > { > WG
activities."
> { > { > { > { > > I have not seen that the PCN charter 
> excludes { > other { > { > types { > of aggregation.
> { > { > { > { >
> { > { > { > { > > that I am refering to the HOSE model where 
> the { > { > traffic { > sent { > by one or { > > more than 
> one { > ingresses { > towards one { > egress is aggregated at 
> the { > { > > egress. In { > this way higgher { > traffic 
> aggregation can { > be accomplished { > { > > than in the { > 
> situation that the { > pipe/trunk { > { > 
> (ingress-egress-aggregate) { > { > > is { > used, where the { 
> traffic sent by only one ingress in { > { > aggegated at { > > > the
egress.
> { > { > { > { >
> { > { > { > { > Typically the "hose" model refers to { > { > 
> { > { > { > { Georgios: Typically yes, but in this case we 
> refer { > to { { > bandwidth allocation { in a 
> multipoint-to-point fashion.
> { > { > { > {
> { > { > { > { >
> { > { > { > { >
> { > { > { > { > Regards,
> { > { > { > { >
> { > { > { > { > // Steve
> { > { > { > { >
> { > { > { > {
> { > { > { > {

---

From: <[email-masked]>
Date: Wed, 27 Aug 2008 13:48:49 +0100

2475:
2.  Differentiated Services Architectural Model

   The differentiated services architecture is based on a simple model
   where traffic entering a network is classified and possibly
   conditioned at the boundaries of the network, and assigned to
   different behavior aggregates.

Note "entering".

Anyway, this sub-thread has gone on too long already. We're arguing
about irrelevant detail. Looking forward to answers on the earlier
points raised. 

Best wishes
Phil. 

{ -----Original Message-----
{ From: Georgios Karagiannis [mailto:[email-masked]]
{ Sent: 27 August 2008 13:40
{ To: Eardley,PL,Philip,CXR9 R; [email-masked]
{ Cc: [email-masked]
{ Subject: RE: [PCN] PCN WG last call for
draft-ietf-pcn-architecture-05.txt
{ 
{ Hi Phil
{ 
{ Your explanations are right, but regarding the explanation over
{ Diffserv, please note that this is only one of the possible views.
{ 
{ In a HOSE model two aggregated bandwidth specifications per node could
be
{ used:
{ 
{ Incomning aggregated bandwdith: associated with the incoming traffic
from
{ all other nodes
{ This is the HOSE model view that I was refereing to.
{ 
{ Outgoing aggregated bandwdith: the amount of the aggregated traffic
that
{ the
{ node can send towards all other nodes.
{ This is the version that you were referring as Diffserv hose model.
{ 
{ The Duffield Hose model specification uses both aggregated bandwidth
{ specifications listed above.
{ 
{ 
{ 
{ Best regards,
{ Georgios
{ 
{ 
{ 
{ > -----Original Message-----
{ > From: [email-masked] [mailto:[email-masked]]
{ > Sent: woensdag 27 augustus 2008 14:03
{ > To: [email-masked]; [email-masked]
{ > Cc: [email-masked]
{ > Subject: RE: [PCN] PCN WG last call for
{ > draft-ietf-pcn-architecture-05.txt
{ >
{ > You appear to be saying all 3 definitions are the same. I
{ > think they're all different.
{ >
{ > Let's call the gateway nodes A, B, C, D ,E and F.
{ >
{ > Duffield: hose at A is all traffic to b,c,d,e,f and all
{ > traffic from b,c,d,e,f
{ >
{ > DiffServ: hose at A is all traffic to b,c,d,e,f
{ >
{ > Georgios: hose at A is all traffic from b,c,d,e,f
{ >
{ > { -----Original Message-----
{ > { From: Georgios Karagiannis [mailto:[email-masked]]
{ > { Sent: 27 August 2008 12:56 { To: Eardley,PL,Philip,CXR9 R;
{ > [email-masked] { Cc: [email-masked] { Subject: RE:
{ > [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt
{ > {
{ > { Hi Phil
{ > {
{ > { Assuming that ingresses can only send data traffic and
{ > egresses can { receive { data traffic, { a HOSE model that is
{ > used in the PCN domain between ingress nodes and { egress {
{ > edge nodes, { is refering to aggregates between ingress and
{ > egress edge nodes, where { ingresses are { sending traffic
{ > and egresses are receiving data traffic.
{ > {
{ > { Thus the HOSE aggregation model used in PCN is a HOSE
{ > aggregation model { used between ingress and egress nodes.
{ > {
{ > {
{ > { Best regards,
{ > { Georgios
{ > {
{ > { > -----Original Message-----
{ > { > From: [email-masked]
{ > [mailto:[email-masked]] { > Sent: woensdag 27 augustus
{ > 2008 13:35 { > To: [email-masked];
{ > [email-masked] { > Cc: [email-masked] { > Subject: RE:
{ > [PCN] PCN WG last call for { > draft-ietf-pcn-architecture-05.txt
{ > { >
{ > { > I note that the Duffield et al definition below is
{ > different { > from what your talking about, since their
{ > definition includes { > traffic in both directions, whilst
{ > yours is a one way { > definition. I think other people, with
{ > a DiffServ { > architecture background, would interpret it as
{ > traffic from { > one ingress going to any egress. So that's 3
{ > possibilities.
{ > { >
{ > { > In any case, this is really a side issue, compared with
{ > my { > main points /questions in earlier email.
{ > { >
{ > { > { -----Original Message-----
{ > { > { From: Georgios Karagiannis
{ > [mailto:[email-masked]] { > { Sent: 27 August 2008
{ > 11:37 { To: Eardley,PL,Philip,CXR9 R; { >
{ > [email-masked] { Cc: [email-masked] { Subject: RE:
{ > { > [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt
{ > { > {
{ > { > { Hi Phil
{ > { > {
{ > { > { HOSE model is defined some 20 years ago, please see e.g
{ > the { > following { article:
{ > { > {
{ > { > { N. G. Duffield, P. Goyal and A. Greenberg, "A Flexible
{ > { > Model { for Resource Management in Virtual Private Networks",
in:
{ > { > { Proc. of ACM SIGCOMM, 1999.
{ > { > {
{ > { > { In the above article I found the following definition:
{ > { > {
{ > { > { "A hose is characterized by the aggregate traffic { to
{ > and { > from one endpoint in the VPN to the set of other {
{ > endpoints { > in the VPN"
{ > { > {
{ > { > { Thus the definition refers to aggregated traffic to and
{ > { > from one edge to { and { from all other endpoints.
{ > { > {
{ > { > {
{ > { > { In our case we refer only to the aggregated traffic
{ > from { > other endpoints { to { one endpoint.
{ > { > {
{ > { > { Thus what we use is in line with the definition of the
{ > HOSE model.
{ > { > {
{ > { > { Best regards,
{ > { > { Georgios
{ > { > {
{ > { > {
{ > { > {
{ > { > {
{ > { > { > -----Original Message-----
{ > { > { > From: [email-masked]
{ > { > [mailto:[email-masked]] { > Sent: woensdag 27
{ > augustus { > 2008 11:31 { > To: [email-masked]; { >
{ > [email-masked] { > Cc: [email-masked] { > Subject: RE:
{ > { > [PCN] PCN WG last call for { >
draft-ietf-pcn-architecture-05.txt
{ > { > { >
{ > { > { > I thought your emails with steve had revealed that
{ > your { > model { > was the exact opposite of the well known
{ > hose model?
{ > { > { >
{ > { > { >
{ > { > { > { -----Original Message-----
{ > { > { > { From: Georgios Karagiannis
{ > { > [mailto:[email-masked]] { > { Sent: 27 August
{ > 2008 { > 09:41 { To: Eardley,PL,Philip,CXR9 R; { > { >
{ > [email-masked] { Cc: [email-masked] { Subject: RE:
{ > { > { > [PCN] PCN WG last call for
draft-ietf-pcn-architecture-05.txt
{ > { > { > {
{ > { > { > { Hi Phil
{ > { > { > {
{ > { > { > { What I explained is the well know HOSE bandwidth {
{ > > management model.
{ > { > { > { During the IETF in Dublin, Hein also shown also
{ > some { { > > results { that were obtrained using the HOSE model.
{ > { > { > {
{ > { > { > {
{ > { > { > { Best regards,
{ > { > { > { Georgios
{ > { > { > {
{ > { > { > {
{ > { > { > { > -----Original Message-----
{ > { > { > { > From: [email-masked]
{ > { > { > [mailto:[email-masked]] { > Sent: woensdag 27
{ > { > augustus { > 2008 10:20 { > To: [email-masked]; {
{ > { > [email-masked] { > Cc: [email-masked] { > Subject: > RE:
{ > { > { > [PCN] PCN WG last call for { >
{ > draft-ietf-pcn-architecture-05.txt
{ > { > { > { >
{ > { > { > { > So the question is about adding to the draft:
{ > { > { > { > A model where the egress measures marks coming
{ > from { > all { > the { > ingresses, and makes admission
{ > decision based on that.
{ > { > { > { >
{ > { > { > { > Before adding anything about this to the draft,
{ > I'd { > like { > to { > understand if this is a genuine
{ > practical, { > understood { > option { > (if so, OK), or if
{ > it's a { > theoretical possibility { > or one not { > well
understood.
{ > { > { > { > (there are many things in the latter category
{ > that { > aren't { > { > mentioned in the draft.) { > { >
{ > Questions are { > why this { > is interesting, why is it
{ > better than { > the { > models already { > well-known, are
{ > there comparative analysis { > { > /simulations?
{ > { > { > { >
{ > { > { > { > I suppose I've got 2 general issues:
{ > { > { > { > [1] every time something is added, overall the {
{ > > document { { > becomes harder to understand, more daunting
{ > to { > read & it { > > looks { less { like the WG has consensus.
{ > { > { > { > [2] this is an INFO doc. People are free to
{ > invent { > ways { > of { > using the standards pieces other
{ > than the { > architecture { > draft { > says, and indeed in
{ > ways not yet dreamt of.
{ > { > { > { >
{ > { > { > { > Phil.
{ > { > { > { >
{ > { > { > { > { -----Original Message----- { > { > { > { From:
{ > [email-masked] { > { > [mailto:[email-masked]] On
{ > { > Behalf Of { Georgios { > { > Karagiannis { Sent: 27
{ > August 2008 08:54 { > { To: 'Steven Blake'
{ > { > { > { > { Cc: [email-masked]
{ > { > { > { > { Subject: Re: [PCN] PCN WG last call for { > { >
{ > { > draft-ietf-pcn-architecture-05.txt
{ > { > { > { > {
{ > { > { > { > { Hi Steven
{ > { > { > { > {
{ > { > { > { > { > -----Original Message----- { > { > { > { >
{ > From: Steven Blake { > [mailto:[email-masked]] { { >
{ > > { > Sent: woensdag 27 { > augustus 2008 6:18 { > To:
{ > Georgios { { > Karagiannis { > Cc:
{ > { > [email-masked] { > Subject: RE: [PCN] PCN > { > WG { last {
{ > { > call for { > draft-ietf-pcn-architecture-05.txt
{ > { > { > { > { >
{ > { > { > { > { > On Tue, 2008-08-26 at 16:11 +0200, Georgios
{ > Karagiannis { > wrote:
{ > { > { > { > { >
{ > { > { > { > { > > Hi Steven
{ > { > { > { > { > >
{ > { > { > { > { > >
{ > { > { > { > { > > Please see in line!
{ > { > { > { > { > >
{ > { > { > { > { > >
{ > { > { > { > { > > > -----Original Message----- { > { > { > >
{ > > { > From: Steven Blake { > [mailto:[email-masked]]
{ > { { > { > > > > Sent: dinsdag 26 { > augustus 2008 14:46 { > > > To:
{ > { > { > { > Georgios Karagiannis { > > > Cc: [email-masked] { >
{ > > > { > { > { > Subject: Re: [PCN] PCN WG last call for { > >
{ > > { > { { > draft-ietf-pcn-architecture-05.txt
{ > { > { > { > { > > >
{ > { > { > { > { > > > On Tue, 2008-08-26 at 11:44 +0000,
{ > Georgios { > Karagiannis { > wrote:
{ > { > { > { > { > > >
{ > { > { > { > { > > > > Hi Phil, Hi all
{ > { > { > { > { > > > >
{ > { > { > { > { > > > > Here are some  comments on the PCN { >
{ > architecture draft:
{ > { > { > { > { > > > >
{ > { > { > { > { > > > > 1) Thank you for clarifying the bullet
{ > in { { > Setion { > 3.2 about flow { > > > > termination.
{ > { > { > { > { > > > >
{ > { > { > { > { > > > > 2) From what I understand the PCN { >
{ > architecture { > { > draft { > > > mentions that PCN { > > >
{ > { > > supports only { > the { > trunk
{ > (ingress-egress-aggregate) { > and not the { > > > { > > HOSE model.
{ > { > { > { > { > > > > Is the PCN architecture draft excluding
{ > { > { > solutions { > that { > support the { > > > > HOSE
{ > model? If { { > not, please { > emphasize in the PCN { >
{ > architecture draft { > { >
{ > > >
{ > { >
{ > { that { > "solutions that are based on other types { > of >
{ > flow { { > > > { > { > { > { { > aggregation than { > > > >
{ > the { > { > ingress-egress-aggregate { > method of flow { > {
{ > aggregation, { > are not { > > > > excluded { > from the PCN > { >
WG
{ activities."
{ > { > { > { > { > > >
{ > { > { > { > { > > > Actually they are, by our charter.
{ > { > { > { > { > >
{ > { > { > { > { > > I have not seen that the PCN charter
{ > excludes { > other { > { > types { > of aggregation.
{ > { > { > { > { >
{ > { > { > { > { > Well, I checked, and you are correct (mea culpa).
{ > { > { > { > { Georgios: No problem
{ > { > { > { > {
{ > { > { > { > { >
{ > { > { > { > { > > Please note
{ > { > { > { > { > > that I am refering to the HOSE model where
{ > the { > { > traffic { > sent { > by one or { > > more than
{ > one { > ingresses { > towards one { > egress is aggregated at
{ > the { > { > > egress. In { > this way higgher { > traffic
{ > aggregation can { > be accomplished { > { > > than in the { >
{ > situation that the { > pipe/trunk { > { >
{ > (ingress-egress-aggregate) { > { > > is { > used, where the {
{ > traffic sent by only one ingress in { > { > aggegated at { > > > the
{ egress.
{ > { > { > { > { >
{ > { > { > { > { > Typically the "hose" model refers to { > { >
{ > point-to-multipoint { > { > traffic flow, not multipoint-to-point.
{ > { > { > { > { Georgios: Typically yes, but in this case we
{ > refer { > to { { > bandwidth allocation { in a
{ > multipoint-to-point fashion.
{ > { > { > { > {
{ > { > { > { > { >
{ > { > { > { > { >
{ > { > { > { > { > Regards,
{ > { > { > { > { >
{ > { > { > { > { > // Steve
{ > { > { > { > { >
{ > { > { > { > {
{ > { > { > { > {
{ > { > { > { > { _______________________________________________
{ > { > { > { > { PCN mailing list
{ > { > { > { > { [email-masked]
{ > { > { > { > { https://www.ietf.org/mailman/listinfo/pcn
{ > { > { > { >
{ > { > { > {
{ > { > { >
{ > { > {
{ > { >
{ > {
{ >
{

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 27 Aug 2008 15:15:18 +0200

Hi Phil

What I was trying to say in the previous emails is that the definition of
the HOSE aggregation model 
covers a wide area, and its interpretation varies depending on the context
that it is used.

> the models already well-known, are there comparative analysis 

Georgios: It is interesting because is more scalable than the
ingress-egress-aggregation model and 
because the level of flow aggregation (and thus the level of statistical
aggregation) 
that can be achieved is higher than in the IEA case.

> looks less like the WG has consensus.

Georgios: I think that the sentence proposed by you, see below (with an
addition from my side)
is clear enough:
"An aggregation model where the egress measures marks coming from all the 
ingresses, and makes admission decision based on that." 

> says, and indeed in ways not yet dreamt of. 

Georgios: I am not sure if this is always true, that is why I would 
like to see somethink like the sentence given above.

Best regards,
Georgios

---

From: <[email-masked]>
Date: Wed, 27 Aug 2008 16:32:30 +0100

{ > So the question is about adding to the draft:
{ > A model where the egress measures marks coming from all the
{ > ingresses, and makes admission decision based on that.
{ >
{ > Before adding anything about this to the draft, I'd like to
{ > understand if this is a genuine practical, understood option
{ > (if so, OK), or if it's a theoretical possibility or one not
{ > well understood.
{ > (there are many things in the latter category that aren't
{ > mentioned in the draft.)
{ >
{ > Questions are why this is interesting, why is it better than
{ > the models already well-known, are there comparative analysis
{ > /simulations?
{ 
{ Georgios: It is interesting because is more scalable than the
{ ingress-egress-aggregation model and
{ because the level of flow aggregation (and thus the level of
statistical
{ aggregation)
{ that can be achieved is higher than in the IEA case.

I don't really believe either of these claims. 
On scalability, what's the scenario? Eg imagine a core network with 100
or so gateway pcn-nodes. Whether an egress node is recording marking
info per ingress node (100 pieces of info) or recording it whatever the
ingress (1 piece of info) - is this really a significant scaling
difference? Especially when you remember that the PCN-ingress-nodes keep
per flow state for policing purposes.

On aggregation, I actually think the opposite is true. In your case, you
can get a focused overload: many flows happen to focus on a particular
link and then all flows through the congested link fail
catastrophically. With PCN (ie ingress-egress-aggregates) the finer
grained info should prevent this happening. So your scheme has to be
more cautious about how much traffic it admits (eg by setting the
PCN-threshold-rate lower).

{ 
{ 
{ >
{ Georgios: I think that the sentence proposed by you, 

it most certainly wasn't proposed by me

see below (with an
{ addition from my side)
{ is clear enough:
{ "An aggregation model where the egress measures marks coming from all
the
{ ingresses, and makes admission decision based on that."

my point was different. It wasn't about the clarity or not of the
sentence.

{ 
{ 
{ > [2] this is an INFO doc. People are free to invent ways of
{ > using the standards pieces other than the architecture draft
{ > says, and indeed in ways not yet dreamt of.
{ 
{ Georgios: I am not sure if this is always true, that is why I would
{ like to see somethink like the sentence given above.

What I wrote seems true. Indeed, in general if subsequent experience
shows that Info docs haven't captured important ways in which Stds docs
are being used in practice, then docs get revised. 

{ 
{ Best regards,
{ Georgios
{ 
{ 
{ >
{ > Phil.
{ >

---

From: "HUBLET Christian" <[email-masked]>
Date: Wed, 27 Aug 2008 18:39:49 +0200

Two small remarks on the draft which has improved a lot over time
compared to previous versions of the document:
	- section 6.2: second bullet
			if excess marked traffic is measured and excess
marked packets are dropped,
			I would assume that this will result in
undertermination and a slower termination process 
			i.s.o. of the mentioned overtermination.
	- section 6.3: figure 2 does not line up with 2 state marking.
			excess marking and threshold marking is
mentioned, 
			I would assume only threshold marking is used
(even for admittance).
			rest of the figure looks OK.

Kr,

Chris

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Steven Blake
Sent: vrijdag 22 augustus 2008 14:35
To: pcn
Subject: Re: [PCN] PCN WG last call for
draft-ietf-pcn-architecture-05.txt

On Fri, 2008-08-08 at 20:03 -0400, Steven Blake wrote:

> as an Informational RFC.  Substantive comments and statements of 
> support for this draft should be sent to the pcn mailing list.  
> Editorial suggestions can be sent directly to the document editor.

Regards,

// Steve

---

From: <[email-masked]>
Date: Thu, 28 Aug 2008 09:27:31 +0100

Thanks for your supportive remarks, and spotting these 2 errors
phil
{ 	- section 6.3: figure 2 does not line up with 2 state marking.
{ 			excess marking and threshold marking is
{ mentioned,
{ 			I would assume only threshold marking is used
{ (even for admittance).
{ 			rest of the figure looks OK.

Thanks. in fact only excess marking is used. 
Above PCN-excess-rate, it should read "Some pkts excess-traffic-marked"
Above U*PCN-excess-rate, it should read "Further pkts
excess-traffic-marked" 

(sorry, I don't know what happened here. I remember copying Figure 1 and
making the appropriate changes, but somehow I must have managed to undo
the changes!!)

---

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 28 Aug 2008 11:44:22 +0200

Georgios,

the hose model on an ingress node requires functionalities treating 
packets irrespective disregarding the destination address and the 
hose model applied to an egress node there require functionalities 
working on all packets disregarding their origin address. 

I've copied in two sections of draft westberg. The mechanisms 
mentioned there with regard to the hose model:
- are obviously not related to the hose model.
- are out of scope of the PCN WG.

I think the WG can go on now.

Regards,

Ruediger

Quotes from draft-westberg-pcn-load-control-04

3.1.2.2.  PCN-egress-node features

   [snip]

   Note that if an edge-to-edge pair aggregated state is not available
   at the PCN-egress-node, e.g., when the HOSE model is used then the
   PCN-egress-node cannot determine whether a PCN-egress-node associated
   with the edge-to-edge pair PCN aggregate operates in Normal state,
   Admission Control state or Flow Termination state.  However, even in
   this case, when a probe packet arrives at the PCN-egress-node, then
   this request should be rejected if the probe packet is PCN_marking
   encoded.  Otherwise, i.e., if the probe packet is not PCN_marking
   encoded, it should be accepted. 

3.2.2.   PCN-egress-node

   [snip]

   Note that in the ingress-egress-aggregate model the excess rate and
   the flows to be terminated are associated with the same edge-to-edge
   (i.e., ingress-egress) pair PCN aggregate and with the same traffic
   class, i.e., PHB.  In the HOSE model the excess rate and the flows to
   be terminated are associated with the same traffic class, i.e., PHB.
   The PCN-egress-node needs to store for each flow the address, e.g.,
   IP address and port number, of the PCN-ingress-node from where the
   particular flow passed before arriving to the PCN-egress-node.  This
   can be for example done by using information that is carried by the
   external protocols used in combination with the LC-PCN solution.  For
   the flows that should be terminated the PCN-egress-node informs the
   associated PCN-ingress-node to terminate them.  If the PCN domain
   uses thet ingress-egress-aggregate model and if the PCN-egress-node
   receives any admission flow request, belonging to a ingress-egress-
   aggregate state operating in flow termination state then the request
   must be rejected. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Georgios Karagiannis
Sent: Wednesday, August 27, 2008 12:37 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt

Hi Phil

Best regards,
Georgios

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 28 Aug 2008 12:44:34 +0200

Hi Ruediger

As I shown in previous emails, the definition of the HOSE model covers an
wide area 
and its interpretation depends on the context.
Thus the mentioned model can be seen as a HOSE model in the PCN context.

As you could follow the discussion with Steven, this model is 
not out of the PCN WG scope.

Best regards,
Georgios

> From: Geib, Ruediger [mailto:[email-masked]] 
> Sent: donderdag 28 augustus 2008 11:44
> To: [email-masked]
> Cc: [email-masked]
> the hose model on an ingress node requires functionalities 
> treating packets irrespective disregarding the destination 
> address and the hose model applied to an egress node there 
> require functionalities working on all packets disregarding 
> their origin address. 
> 
> Behalf Of Georgios Karagiannis
> "A hose is characterized by the aggregate traffic to and from 
> one endpoint in the VPN to the set of other endpoints in the VPN"
> 
> Thus the definition refers to aggregated traffic to and from 
> one edge to and from all other endpoints.
>  
> 
> In our case we refer only to the aggregated traffic from 
> other endpoints to one endpoint.
> 
> > { From: Georgios Karagiannis 
> [mailto:[email-masked]] { Sent: 
> > 27 August 2008 09:41 { To: Eardley,PL,Philip,CXR9 R; 
> > { > A model where the egress measures marks coming from all the { > 
> > { > Before adding anything about this to the draft, I'd like to { > 
> > understand if this is a genuine practical, understood 
> option { > (if 
> > so, OK), or if it's a theoretical possibility or one not { > well 
> > understood.
> > { > (there are many things in the latter category that aren't { > 
> > mentioned in the draft.) { > { > Questions are why this is 
> > interesting, why is it better than { > the models already 
> well-known, 
> > are there comparative analysis { > /simulations?
> > { >
> { becomes 
> > harder to understand, more daunting to read & it { > > looks less
> > { > [2] this is an INFO doc. People are free to invent ways of { > 
> > using the standards pieces other than the architecture 
> draft { > says, 
> > { Sent: 27 August 2008 08:54 { > { To: 'Steven Blake'
> > { > { Cc: [email-masked]
> > { > WG 
> > last
> > { > { > > > -----Original Message----- { > { > > > From: 
> Steven Blake 
> > [mailto:[email-masked]] { { > > > > Sent: dinsdag 
> 26 augustus 
> > 2008 14:46 { > > > To:
> > { > { > > > > 2) From what I understand the PCN 
> architecture { > draft 
> > { > > > mentions that PCN { > > > > supports only the { > trunk 
> > (ingress-egress-aggregate) and not the { > > >
> > > HOSE model.
> > { > { > > > > Is the PCN architecture draft excluding solutions { > 
> > that { > support the { > > > > HOSE model? If not, please { > 
> > emphasize in the PCN { > architecture draft {
> > > > > that { > "solutions that are based on other types of 
> > flow { > 
> > > > > > >
> > ingress-egress-aggregate { > method of flow { > 
> aggregation, are not { 
> > > > > > excluded { > from the PCN WG activities."
> > { > { > > >
> > { > { > > I have not seen that the PCN charter excludes other { > 
> traffic { > 
> > sent { > by one or { > > more than one ingresses towards one { > 
> > egress is aggregated at the { > > egress. In this way higgher { > 
> > traffic aggregation can be accomplished { > > than in the { > 
> > situation that the pipe/trunk { >
> traffic sent 
> > by only one ingress in { > aggegated at { > > the egress.
> > { > { >
> point-to-multipoint { > {

---

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 28 Aug 2008 12:52:25 +0200

Georgios,

please argue like a sales representative with managers.

But not with me on this list.

Regards,

Ruediger 

-----Original Message-----
From: Georgios Karagiannis [mailto:[email-masked]] 
Sent: Thursday, August 28, 2008 12:45 PM
To: Geib, Rüdiger
Cc: [email-masked]
Subject: RE: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt

Hi Ruediger

Best regards,
Georgios

---

From: ken carlberg <[email-masked]>
Date: Thu, 28 Aug 2008 07:21:10 -0400

whoa.  let's take a timeout and catch our breadths for a moment before  
this starts to turn ugly.  there has been a lengthy exchange on the  
list and some of it appears to have now reached a point where folks  
are talking past each other.

with respect to the Hose model, I don't have a strong conviction abut  
it one way or the other.  Elements of what Georgios says grab my  
attention, but the points being made seem to resemble a moving target,  
so I don't become convinced about its inclusion into the Architecture  
document as it stands right now.  Perhaps a way to get beyond this  
impasse is to tweak the Architecture document a bit so that it  
acknowledges that other models (without mentioning the Hose model per  
se) may be put forth and agreed upon in the future and leave it at  
that.  (Phil, if this tweaking already exists or has been done, then  
great, sorry I missed it, and let's move on)

-ken

ps, its probably helpful to get some additional stronger guidance from  
the Chairs and/or ADs at this point as well.

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 28 Aug 2008 12:30:20 +0100

Georgios,

I've started a different thread on this, because I think there is 
general consensus that it is not relevant to the last call on the 
current PCN architecture.

Bringing in a completely different architecture at the last minute 
requires another informational doc about that architecture, not 
holding up the current one. Here's why I say it's a completely 
different architecture...

Using your multipoint-to-point (MP2P) (so-called 'hose') scenario and 
Phil's notation from earlier in the thread below, with traffic from 
b,c,d,e,f to A.

b___X__________
c___________   \
             \   \
d------------+---+--> A
e___________/   /
f______________/

- if there's high pre-congestion on link X just after traffic leaves b (say)
- but traffic from c,d,e,f to A doesn't go through this pre-congested link
- you claim A can average all the markings from b,c,d,e,f together,
- giving an average for the MP2P aggregate lower than pre-congestion on b-A
- then A could continue to tell any of b,c,d,e,f to accept new flows
- then flows will still be added to a highly pre-congested path b-A

If you have invented a way to solve this problem, it will involve 
discriminating between each of the ingress-egress paths within the 
MP2P aggregate (perhaps using affected marking). So you will need to 
store state for each path and you're no longer storing just a single 
state for the MP2P aggregate any more.

In MPLS fora, the implications of allowing MP2P aggregates have 
caused years of arguments. We didn't include MP2P in the PCN 
architecture for a very good reason: you cannot create the assurances 
we're trying to create with MP2P aggregates. If you want an assured 
MP2P aggregate, you have to build it using a set of P2P 
(point-to-point) aggregates.

We're doing other work on MP2P aggregates, but we're not bringing it 
to the PCN w-g. Please respect that the IETF has to limit the scope 
of each work item in order to achieve anything.

Finally, if you've ever watered your garden with a hose that sucks 
the water off the grass back into the hose, then I will allow you to 
use the term hose for an MP2P aggregate. Until you can demonstrate 
this feat experimentally in your garden, please use words that mean 
what they say. Video footage running backwards will not be acceptable evidence.

Bob

>draft-ietf-pcn-architecture-05.txt

____________________________________________________________________________
Bob Briscoe, <[email-masked]>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 28 Aug 2008 13:46:06 +0200

Hi Ken

I agree with your proposal!
 
> Perhaps a way to get beyond this impasse 
> is to tweak the Architecture document a bit so that it 
> se) may be put forth and agreed upon in the future and leave 
> it at that.

Best regards,
Georgios

> From: ken carlberg [mailto:[email-masked]] 
> Sent: donderdag 28 augustus 2008 13:21
> To: Geib, Ruediger
> Cc: [email-masked]; [email-masked]
> whoa.  let's take a timeout and catch our breadths for a 
> moment before this starts to turn ugly.  there has been a 
> lengthy exchange on the list and some of it appears to have 
> now reached a point where folks are talking past each other.
> 
> with respect to the Hose model, I don't have a strong 
> conviction abut it one way or the other.  Elements of what 
> Georgios says grab my attention, but the points being made 
> seem to resemble a moving target, so I don't become convinced 
> about its inclusion into the Architecture document as it 
> stands right now.  Perhaps a way to get beyond this impasse 
> is to tweak the Architecture document a bit so that it 
> se) may be put forth and agreed upon in the future and leave 
> it at that.  (Phil, if this tweaking already exists or has 
> been done, then great, sorry I missed it, and let's move on)
> 
> -ken
> 
> ps, its probably helpful to get some additional stronger 
> guidance from the Chairs and/or ADs at this point as well.
> 
> 
> > As I shown in previous emails, the definition of the HOSE 
> model covers 
> > an wide area and its interpretation depends on the context.
> > As you could follow the discussion with Steven, this model 
> is not out 
> > of the PCN WG scope.
> >
> > Best regards,
> > Georgios
> >
> >
> >
> >
> treating 
> >>   class, i.e., PHB.  In the HOSE model the excess rate and 
> the flows 
> >> to
> >>   external protocols used in combination with the LC-PCN 
> solution.  
> >> For
> >> Georgios Karagiannis
> >> N. G. Duffield, P. Goyal and A. Greenberg, "A Flexible Model for 
> >> Resource Management in Virtual Private Networks", in:
> >> "A hose is characterized by the aggregate traffic to and from one 
> >> endpoint in the VPN to the set of other endpoints in the VPN"
> >>
> >> Thus the definition refers to aggregated traffic to and 
> from one edge 
> >> to and from all other endpoints.
> >>
> >>
> >> In our case we refer only to the aggregated traffic from other 
> >> endpoints to one endpoint.
> >>
> >>> Karagiannis { > Cc: [email-masked] { > Subject: RE: [PCN] 
> PCN { > WG 
> >>> last
> solutions { >

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 28 Aug 2008 14:14:39 +0200

Hi Bob

I do not want to hold the publication of the architecture draft.
I will be happy if, related to this issue, the sentence proposed by 
Ken in the previous email is used.

Regarding one of your comments:

> If you want an assured MP2P aggregate, you have to build it 
> using a set of P2P

Georgios: using a set of P2P aggregates to achieve this is not required.
The MP2P aggregation is solved by using affected marking and just using one
state.
Please also note that at the same time this solution solves the ecmp
problem.

Best regards,
Georgios

> From: Bob Briscoe [mailto:[email-masked]] 
> Sent: donderdag 28 augustus 2008 13:30
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: MP2P aggregates (was: [PCN] PCN WG last call for 
> draft-ietf-pcn-architecture-05.txt)
> 
> Georgios,
> 
> I've started a different thread on this, because I think 
> there is general consensus that it is not relevant to the 
> last call on the current PCN architecture.
> 
> Bringing in a completely different architecture at the last 
> minute requires another informational doc about that 
> architecture, not holding up the current one. Here's why I 
> say it's a completely different architecture...
> 
> Using your multipoint-to-point (MP2P) (so-called 'hose') 
> scenario and Phil's notation from earlier in the thread 
> below, with traffic from b,c,d,e,f to A.
> 
> b___X__________
> c___________   \
>              \   \
> d------------+---+--> A
> e___________/   /
> f______________/
> 
> If you have invented a way to solve this problem, it will 
> involve discriminating between each of the ingress-egress 
> paths within the MP2P aggregate (perhaps using affected 
> marking). So you will need to store state for each path and 
> you're no longer storing just a single state for the MP2P 
> aggregate any more.
> 
> In MPLS fora, the implications of allowing MP2P aggregates 
> have caused years of arguments. We didn't include MP2P in the 
> PCN architecture for a very good reason: you cannot create 
> the assurances we're trying to create with MP2P aggregates. 
> If you want an assured MP2P aggregate, you have to build it 
> using a set of P2P
> We're doing other work on MP2P aggregates, but we're not 
> bringing it to the PCN w-g. Please respect that the IETF has 
> to limit the scope of each work item in order to achieve anything.
> 
> Finally, if you've ever watered your garden with a hose that 
> sucks the water off the grass back into the hose, then I will 
> allow you to use the term hose for an MP2P aggregate. Until 
> you can demonstrate this feat experimentally in your garden, 
> please use words that mean what they say. Video footage 
> running backwards will not be acceptable evidence.
> 
> 
> Bob
> 
> { Sent: 27 
> >August 2008 12:56 { To: Eardley,PL,Philip,CXR9 R; 
> [PCN] PCN WG 
> >last call for draft-ietf-pcn-architecture-05.txt
> >{
> >{ Hi Phil
> >{
> egresses can { 
> >receive { data traffic, { a HOSE model that is used in the 
> PCN domain 
> >between ingress nodes and { egress { edge nodes, { is refering to 
> >aggregates between ingress and egress edge nodes, where { 
> ingresses are 
> >model { used between ingress and egress nodes.
> >{
> >{
> >{ Best regards,
> >{ Georgios
> >{
> >{ > From: [email-masked] [mailto:[email-masked]] { > 
> >Sent: woensdag 27 augustus 2008 13:35 { > To: 
> [email-masked]; 
> [PCN] PCN 
> >{ > I note that the Duffield et al definition below is different { > 
> >from what your talking about, since their definition includes { > 
> >traffic in both directions, whilst yours is a one way { > 
> definition. I 
> >think other people, with a DiffServ { > architecture 
> background, would 
> >interpret it as traffic from { > one ingress going to any egress. So 
> >that's 3 possibilities.
> >{ >
> [mailto:[email-masked]] { > { 
> >Sent: 27 August 2008 11:37 { To: Eardley,PL,Philip,CXR9 R; { > 
> >{ > { HOSE model is defined some 20 years ago, please see 
> e.g the { > 
> >following { article:
> >{ > {
> { > Model 
> >{ > { "A hose is characterized by the aggregate traffic { to and { > 
> { > in the 
> >VPN"
> >{ > { Thus the definition refers to aggregated traffic to 
> and { > from 
> >one edge to { and { from all other endpoints.
> >{ > {
> >{ > {
> >{ > { In our case we refer only to the aggregated traffic from { > 
> augustus { > 
> >2008 11:31 { > To: [email-masked]; { > 
> [email-masked] { 
> >> Cc: [email-masked] { > Subject: RE:
> >{ > { > I thought your emails with steve had revealed that your { > 
> >{ > [mailto:[email-masked]] { > { Sent: 27 August 2008 { > 
> >09:41 { To: Eardley,PL,Philip,CXR9 R; { > { > 
> [email-masked] { 
> >{ > { > { What I explained is the well know HOSE bandwidth { > 
> >management model.
> some { { > > 
> >{ > { > { > From: [email-masked] { > { > 
> >[mailto:[email-masked]] { > Sent: woensdag 27 { > 
> augustus { > 
> >2008 10:20 { > To: [email-masked]; { > { > 
> from { > all 
> >{ > { > { > Before adding anything about this to the draft, I'd { > 
> >like { > to { > understand if this is a genuine practical, { > 
> >understood { > option { > (if so, OK), or if it's a { > theoretical 
> >possibility { > or one not { > well understood.
> >{ > { > { > (there are many things in the latter category that { > 
> >aren't { > { > mentioned in the draft.) { > { > Questions 
> are { > why 
> >this { > is interesting, why is it better than { > the { > models 
> >already { > well-known, are there comparative analysis { > { > 
> >/simulations?
> >{ > { > { >
> >{ { > becomes harder to understand, more daunting to { > 
> read & it { > 
> >> looks { less { like the WG has consensus.
> invent { > ways 
> >{ > of { > using the standards pieces other than the { > 
> architecture { 
> >[email-masked] { > { > [mailto:[email-masked]] On { > 
> >Behalf Of { Georgios { > { > Karagiannis { Sent: 27 August 
> 2008 08:54 { 
> >> { To: 'Steven Blake'
> >{ > { > { > { Subject: Re: [PCN] PCN WG last call for { > { > { > 
> From: Steven 
> >Blake { > [mailto:[email-masked]] { { > > { > Sent: 
> woensdag 27 
> >{ > [email-masked] { > Subject: RE: [PCN] PCN > { > WG { last 
> { { > call 
> >for { > draft-ietf-pcn-architecture-05.txt
> >{ > { > { > { >
> >{ > { > { > { > > > -----Original Message----- { > { > { > > > { > 
> >{ > { > { > Georgios Karagiannis { > > > Cc: [email-masked] { 
> > > > { > { 
> >> { > Subject: Re: [PCN] PCN WG last call for { > > > { > { { > 
> >{ > { > { > { > > > On Tue, 2008-08-26 at 11:44 +0000, Georgios { > 
> >Karagiannis { > wrote:
> >{ > { > { > { > > >
> in { { > 
> >architecture { > { > draft { > > > mentions that PCN { > > > { > > 
> >supports only { > the { > trunk (ingress-egress-aggregate) { 
> and not 
> >{ > { > { > { > > > > Is the PCN architecture draft 
> excluding { > { > 
> { { > not, 
> >please { > emphasize in the PCN { > architecture draft { > { >
> > > >
> >{ >
> flow { { > 
> >> > { > { > { > { { > aggregation than { > > > > the { > { > 
> >ingress-egress-aggregate { > method of flow { > { > aggregation, { > 
> >are not { > > > > excluded { > from the PCN { > WG activities."
> >{ > { > { > { > > >
> >{ > { > { > { > > I have not seen that the PCN charter excludes { > 
> the { > { 
> >> traffic { > sent { > by one or { > > more than one { > 
> ingresses { > 
> >towards one { > egress is aggregated at the { > { > > egress. In { > 
> >this way higgher { > traffic aggregation can { > be 
> accomplished { > { 
> >> > than in the { > situation that the { > pipe/trunk { > { > 
> >(ingress-egress-aggregate) { > { > > is { > used, where the 
> { > traffic 
> >sent by only one ingress in { > { > aggegated at { > > the egress.
> >{ > { > { > { >
> refer { > to 
> >{ { > bandwidth allocation { in a multipoint-to-point fashion.
> >{ > { > { > {
> >{ > { > { > { >
> >{ > { > { > { >
> >{ > { > { > { > Regards,
> >{ > { > { > { >
> >{ > { > { > { > // Steve
> >{ > { > { > { >
> >{ > { > { > {
> >{ > { > { > {

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 28 Aug 2008 13:16:24 +0100

Phil,

I know the last call ended yesterday, but as I think you agreed to 
make some tweaks to the text, you might want to consider this 
addition to "Sec 7.7 Tunnelling" as well.

Current text:
    o  any PCN-marking is copied into the outer header

Suggested new text
    o  any PCN-marking is copied into the outer header

    Note that a tunnel will not provide this behaviour if it complies
    with [RFC3168] tunnelling in either mode, but it will if it complies
    with [RFC4301] IPSec tunnelling.
-----------------------------------------------------------------------

Current text:
    Similarly, in line with the "uniform conceptual model" of [RFC2983]
    and the "full-functionality option" of [RFC3168], the following rule
    is applied if decapsulation is done within the PCN-domain:

Suggested new text
    Similarly, in line with the "uniform conceptual model" of [RFC2983],
    with [RFC4301] and with the "full-functionality mode" of [RFC3168],
    the following rule is applied if decapsulation is done within the PCN-
    domain:
-----------------------------------------------------------------------

Bob

---

From: <[email-masked]>
Date: Thu, 28 Aug 2008 14:16:54 +0100

Sounds good clarification to me, thanks bob

phil

{ -----Original Message-----
{ From: Briscoe,RJ,Bob,XVR9 BRISCORJ R
{ Sent: 28 August 2008 13:16
{ To: Eardley,PL,Philip,CXR9 R
{ Cc: pcn; Steven Blake
{ Subject: Re: [PCN] PCN WG last call for
draft-ietf-pcn-architecture-05.txt
{ 
{ Phil,
{ 
{ I know the last call ended yesterday, but as I think you agreed to
{ make some tweaks to the text, you might want to consider this
{ addition to "Sec 7.7 Tunnelling" as well.
{ 
{ Current text:
{     o  any PCN-marking is copied into the outer header
{ 
{ Suggested new text
{     o  any PCN-marking is copied into the outer header
{ 
{     Note that a tunnel will not provide this behaviour if it complies
{     with [RFC3168] tunnelling in either mode, but it will if it
complies
{     with [RFC4301] IPSec tunnelling.
{
-----------------------------------------------------------------------
{ 
{ Current text:
{     Similarly, in line with the "uniform conceptual model" of
[RFC2983]
{     and the "full-functionality option" of [RFC3168], the following
rule
{     is applied if decapsulation is done within the PCN-domain:
{ 
{ Suggested new text
{     Similarly, in line with the "uniform conceptual model" of
[RFC2983],
{     with [RFC4301] and with the "full-functionality mode" of
[RFC3168],
{     the following rule is applied if decapsulation is done within the
PCN-
{     domain:
{
-----------------------------------------------------------------------
{ 
{ 
{ Bob
{ 
{ At 13:35 22/08/2008, Steven Blake wrote:
{ >On Fri, 2008-08-08 at 20:03 -0400, Steven Blake wrote:
{ >
{ > > This message starts a 2+-week PCN working group last call for
{ advancing
{ > >
{ > >         Title           : Pre-Congestion Notification Architecture
{ > >         Author(s)       : P. Eardley
{ > >         Filename        : draft-ietf-pcn-architecture-05.txt
{ > >         Pages           : 54
{ > >         Date            : 2008-08-07
{ > >
{ > > as an Informational RFC.  Substantive comments and statements of
{ support
{ > > for this draft should be sent to the pcn mailing list.  Editorial
{ > > suggestions can be sent directly to the document editor.
{ > > The last call will end on Wednesday August 27.
{ >
{ >A reminder that this last call closes next Wednesday.
{ >
{ >
{ >Regards,
{ >
{ >// Steve
{ >
{ >_______________________________________________
{ >PCN mailing list
{ >[email-masked]
{ >https://www.ietf.org/mailman/listinfo/pcn
{ 
{
________________________________________________________________________
__
{ __
{ Bob Briscoe, <[email-masked]>      Networks Research Centre, BT
{ Research
{ B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473
{ 645196

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 28 Aug 2008 16:06:39 +0100

Georgios,

>Ken in the previous email is used.

Good, thanks

>Please also note that at the same time this solution solves the ecmp

Pls be careful with the word 'solved'. Affected marking only gives a 
partial solution - if the circumstances happen to be fortunate.

a) If there is pre-congestion on more than one parallel path, the 
metering of marking as a proportion of affected marking becomes a 
confusion of all the paths that are affected. Multiple parallel 
congested links may seem a corner case, but it's not really. PCN is 
intended to deal with unexpected events. Flash crowds rarely affect 
only one path. Disasters also tend not to be well-behaved.

b) queues on interior nodes have to switch into affected mode, and 
decide to switch out of it after some time-out once the congestion 
episode seems to have gone away.

a) and b) can interact, so that one queue is still doing affected 
marking but timing out after an episode has ended, while another 
queue on a parallel path can be starting an episode. Again the 
markings would get confused.

I'm not saying Affected Marking is not interesting (as research) and 
possibly useful, but it relies on a wing and a prayer (excuse the use 
of english idiom - this means it's a rather precarious mechanism that 
isn't very deterministic). I try to separate solid stuff ready for 
standards from research, even tho I do both.

Bob

> > >Cc: [email-masked] { Subject: RE:

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 28 Aug 2008 17:54:01 +0200

Hi Bob

Please see in line!

> Sent: donderdag 28 augustus 2008 17:07
> To: Georgios Karagiannis
> Subject: RE: MP2P aggregates
> 
> Georgios,
> 
> >I will be happy if, related to this issue, the sentence 
> proposed by Ken 
> >in the previous email is used.
> 
> Good, thanks
> 
> > > If you want an assured MP2P aggregate, you have to build 
> it using a 
> > > set of P2P
> >The MP2P aggregation is solved by using affected marking and 
> just using 
> >one state.
> Pls be careful with the word 'solved'. Affected marking only 
> gives a partial solution - if the circumstances happen to be 
> fortunate.
> 
> a) If there is pre-congestion on more than one parallel path, 
> the metering of marking as a proportion of affected marking 
> becomes a confusion of all the paths that are affected. 
> Multiple parallel congested links may seem a corner case, but 
> it's not really. PCN is intended to deal with unexpected 
> events. Flash crowds rarely affect only one path. Disasters 
> also tend not to be well-behaved.

Georgios: This situation is also solved.

> 
> b) queues on interior nodes have to switch into affected 
> mode, and decide to switch out of it after some time-out once 
> the congestion episode seems to have gone away.

Georgios: If the interior mnode goes into flo termination state that
affected marking is used
If it goes out the flow termination then affected marking is not anymore
used.

> 
> a) and b) can interact, so that one queue is still doing 
> affected marking but timing out after an episode has ended, 
> while another queue on a parallel path can be starting an 
> episode. Again the markings would get confused.

Georgios: Affected marking is associated with flow termination. So if a node
is in flow termination will generate affecetd marking traffic.
The egress node will only select flows for termination that contain marked
packets encoded with either Affected marking encoding or with PC_marking
encoding.
So no confusion wiil take place.

> 
> I'm not saying Affected Marking is not interesting (as 
> research) and possibly useful, but it relies on a wing and a 
> prayer (excuse the use of english idiom - this means it's a 
> rather precarious mechanism that isn't very deterministic). I 
> try to separate solid stuff ready for standards from 
> research, even tho I do both.

Georgios: I think that the solution provided by affected mechanism behaves 
deterministic enough.

Best regards,
Georgios

> > > Using your multipoint-to-point (MP2P) (so-called 'hose') scenario 
> > > and Phil's notation from earlier in the thread below, 
> with traffic 
> > > from b,c,d,e,f to A.
> > >
> > > b___X__________
> > > c___________   \
> > >              \   \
> > > d------------+---+--> A
> > > e___________/   /
> > > f______________/
> > >
> > > - if there's high pre-congestion on link X just after 
> traffic leaves 
> > > b (say)
> > > - giving an average for the MP2P aggregate lower than 
> pre-congestion 
> > > on b-A
> > > architecture for a very good reason: you cannot create the 
> > > assurances we're trying to create with MP2P aggregates.
> > > If you want an assured MP2P aggregate, you have to build 
> it using a 
> > > set of P2P
> bringing it 
> > > >Duffield: hose at A is all traffic to b,c,d,e,f and all traffic 
> > > >from b,c,d,e,f
> > > >
> aggregation 
> [mailto:[email-masked]] { >
> different { 
> > > >interpret it as traffic from { > one ingress going to 
> any egress. 
> > > >So that's 3 possibilities.
> > > >{ >
> > > >{ > { "A hose is characterized by the aggregate traffic 
> { to and { 
> > > >{ > { > From: [email-masked] { > 
> > > >[mailto:[email-masked]] { > Sent: woensdag 27
> > > augustus { >
> > > >{ > { > { -----Original Message----- { > { > { From: Georgios 
> > > >Karagiannis { > [mailto:[email-masked]] { > { Sent: 27 
> > > >August 2008 { >
> > > >{ > { > { > -----Original Message----- { > { > { > From: 
> > > >[email-masked] { > { > [mailto:[email-masked]] { > 
> > > >Sent: woensdag 27 { >
> > > augustus { >
> > > >this { > is interesting, why is it better than { > the { 
> models 
> > > >{ > { > { > { Subject: Re: [PCN] PCN WG last call for { 
> > { > { > 
> > > >{ > { > { > { > > > -----Original Message----- { > { > { 
> > > { >
> > > >{ > { > { > { > > > > Hi Phil, Hi all { > { > { > { > > 
> > > { > { > 
> > > >{ > { > > > > Here are some  comments on the PCN { > 
> architecture 
> > > >draft:
> > > >{ > { > { > { > > > >
> > > >architecture { > { > draft { > > > mentions that PCN { > 
> > > { > > 
> > > >ingress-egress-aggregate { > method of flow { > { > 
> aggregation, { 
> > > >towards one { > egress is aggregated at the { > { > > 
> egress. In {

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 28 Aug 2008 17:23:14 +0100

Phil & list,

For a bit of light relief...

I did consider suggesting that an operator wanting to deploy PCN in a 
domain that also used non-IPSec tunnels could create COTS (common 
off-the-shelf) IP in IP tunnels that exhibit the required behaviour 
for PCN by using null encryption  [RFC2410] with ESP (encrypting 
security payload). This would use IPSec to copy ECN at tunnel 
ingress, but not require any key management.

RFC2410 is probably the closest that security people get to smiling.

Bob

---

From: "Geib, Ruediger" <[email-masked]>
Date: Fri, 29 Aug 2008 08:25:30 +0200

Georgios,

sorry for the rude reaction yesterday.

I appreciate the contribution of you and your team to the experiments 
around PCN as I do appreciate all other PCN experiments known to me. 

This holds whether the text of the architecture document remains as 
is or not. 

Regards,

Ruediger 

-----Original Message-----
From: Georgios Karagiannis [mailto:[email-masked]] 
Sent: Thursday, August 28, 2008 12:45 PM
To: Geib, Rüdiger
Cc: [email-masked]
Subject: RE: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt

Hi Ruediger

Best regards,
Georgios

> the flows to
> solution.  For

---

From: "Lars Westberg" <[email-masked]>
Date: Fri, 29 Aug 2008 08:38:42 +0200

I am sorry, but you probably do not know about all experiments regarding PCN even if it was not denoted PCN at that time. We started nine years ago, so there several experiments that have not ben presented in this forum. many of the discussion are identical what we investigated at that time. 

We also discussed the trunk vs hose model (and combination of them) and the issues regarding scalalabillity of the trunk-model is a real issue. The number of trunks is cuasing a N^2 mesh configuration problem. 

-Lasse 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Geib, Ruediger
Sent: den 29 augusti 2008 08:26
To: [email-masked]
Cc: [email-masked]
Subject: Re: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt

Georgios,

I appreciate the contribution of you and your team to the experiments around PCN as I do appreciate all other PCN experiments known to me. 

This holds whether the text of the architecture document remains as is or not. 

Regards,

Ruediger 

-----Original Message-----
From: Georgios Karagiannis [mailto:[email-masked]]
Sent: Thursday, August 28, 2008 12:45 PM
To: Geib, Rüdiger
Cc: [email-masked]
Subject: RE: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt

Hi Ruediger

As I shown in previous emails, the definition of the HOSE model covers an wide area and its interpretation depends on the context.
Thus the mentioned model can be seen as a HOSE model in the PCN context.

As you could follow the discussion with Steven, this model is not out of the PCN WG scope.

Best regards,
Georgios

> packets irrespective disregarding the destination address and the hose 
> model applied to an egress node there require functionalities working 
> on all packets disregarding their origin address.
> 
> Thus the definition refers to aggregated traffic to and from one edge 
> > Karagiannis { > Cc: [email-masked] { > Subject: RE: [PCN] PCN { > WG 
> > last

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 1 Sep 2008 10:03:19 +0200

Hi Ruediger

Thank you for sending this email!
Apology is accepted!

Best regards,
Georgios

> Sent: vrijdag 29 augustus 2008 8:26
> I appreciate the contribution of you and your team to the 
> experiments around PCN as I do appreciate all other PCN 
> experiments known to me. 
> 
> model covers an wide area and its interpretation depends on 
> the context.