[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PCN] MP2P aggregates
Hi Bob
Please see in line!
> -----Original Message-----
> From: Bob Briscoe [mailto:rbriscoe at jungle.bt.co.uk]
> Sent: donderdag 28 augustus 2008 17:07
> To: Georgios Karagiannis
> Cc: philip.eardley at bt.com; slblake at petri-meat.com; pcn at ietf.org
> Subject: RE: MP2P aggregates
>
> Georgios,
>
> At 13:14 28/08/2008, Georgios Karagiannis wrote:
> >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.
>
> Good, thanks
>
> >Regarding one of your comments:
> >
> > > If you want an assured MP2P aggregate, you have to build
> it using a
> > > set of P2P
> > > (point-to-point) aggregates.
> >
> >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.
>
> Pls be careful with the word 'solved'. Affected marking only
>From pcn-bounces at ietf.org Thu Aug 28 08:54:55 2008
Return-Path: <pcn-bounces at ietf.org>
X-Original-To: pcn-archive at optimus.ietf.org
Delivered-To: ietfarch-pcn-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id E021328C152;
Thu, 28 Aug 2008 08:54:55 -0700 (PDT)
X-Original-To: pcn at core3.amsl.com
Delivered-To: pcn at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 8E4103A6CC5
for <pcn at core3.amsl.com>; Thu, 28 Aug 2008 08:54:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.413
X-Spam-Level: *
X-Spam-Status: No, score=1.413 tagged_above=-999 required=5 tests=[AWL=-0.772,
BAYES_05=-1.11, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545,
J_CHICKENPOX_57=0.6, J_CHICKENPOX_72=0.6]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id b6gju-hjww1x for <pcn at core3.amsl.com>;
Thu, 28 Aug 2008 08:54:52 -0700 (PDT)
Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl
[130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 3EEA73A6A43
for <pcn at ietf.org>; Thu, 28 Aug 2008 08:54:51 -0700 (PDT)
Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129])
by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id
m7SFs8C6026929; Thu, 28 Aug 2008 17:54:11 +0200 (MEST)
From: "Georgios Karagiannis" <karagian at cs.utwente.nl>
To: "'Bob Briscoe'" <rbriscoe at jungle.bt.co.uk>
References: <002101c9083b$de8d88c0$810c5982 at dynamic.ewi.utwente.nl>
<4A916DBC72536E419A0BD955EDECEDEC03DAA1CB at E03MVB1-UKBR.domain1.systemhost.net>
<200808281130.m7SBULJA004422 at bagheera.jungle.bt.co.uk>
<001d01c90907$a91beb10$810c5982 at dynamic.ewi.utwente.nl>
<200808281507.m7SF7JtG024242 at bagheera.jungle.bt.co.uk>
Date: Thu, 28 Aug 2008 17:54:01 +0200
Message-ID: <002401c90926$4d6b3a90$810c5982 at dynamic.ewi.utwente.nl>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
In-Reply-To: <200808281507.m7SF7JtG024242 at bagheera.jungle.bt.co.uk>
Thread-Index: AckJJJf6ntHTW0h+RJ+CxdRSYmCyiQAAFyfA
X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3
(rotterdam.ewi.utwente.nl [130.89.10.5]);
Thu, 28 Aug 2008 17:54:14 +0200 (MEST)
Cc: pcn at ietf.org
Subject: Re: [PCN] MP2P aggregates
X-BeenThere: pcn at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PCN WG list <pcn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pcn>,
<mailto:pcn-request at ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/pcn>
List-Post: <mailto:pcn at ietf.org>
List-Help: <mailto:pcn-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcn>,
<mailto:pcn-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: pcn-bounces at ietf.org
Errors-To: pcn-bounces at ietf.org
Hi Bob
Please see in line!
> -----Original Message-----
> From: Bob Briscoe [mailto:rbriscoe at jungle.bt.co.uk]
> Sent: donderdag 28 augustus 2008 17:07
> To: Georgios Karagiannis
> Cc: philip.eardley at bt.com; slblake at petri-meat.com; pcn at ietf.org
> Subject: RE: MP2P aggregates
>
> Georgios,
>
> At 13:14 28/08/2008, Georgios Karagiannis wrote:
> >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.
>
> Good, thanks
>
> >Regarding one of your comments:
> >
> > > If you want an assured MP2P aggregate, you have to build
> it using a
> > > set of P2P
> > > (point-to-point) aggregates.
> >
> >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.
>
> Pls be careful with the word 'solved'. Affected marking only
> gives a 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
>
>
> Bob
>
>
> >Best regards,
> >Georgios
> >
> >
> >
> > > -----Original Message-----
> > > From: Bob Briscoe [mailto:rbriscoe at jungle.bt.co.uk]
> > > Sent: donderdag 28 augustus 2008 13:30
> > > To: karagian at cs.utwente.nl
> > > Cc: philip.eardley at bt.com; slblake at petri-meat.com; pcn at ietf.org
> > > 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 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 o 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
>
>
> Bob
>
>
> >Best regards,
> >Georgios
> >
> >
> >
> > > -----Original Message-----
> > > From: Bob Briscoe [mailto:rbriscoe at jungle.bt.co.uk]
> > > Sent: donderdag 28 augustus 2008 13:30
> > > To: karagian at cs.utwente.nl
> > > Cc: philip.eardley at bt.com; slblake at petri-meat.com; pcn at ietf.org
> > > 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 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 argumef 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
> > >
> > > At 13:03 27/08/2008, philip.eardley at bt.com wrote:
> > > >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:karagian at cs.utwente.nl]
> > > { Sent: 27
> > > >August 2008 12:56 { To: Eardley,PL,Philip,CXR9 R;
> > > >slblake at petri-meat.com { Cc: pcn at ietf.org { 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: philip.eardley at bt.com
> [mailto:philip.eardley at bt.com] { >
> > > >Sent: woensdag 27 augustus 2008 13:35 { > To:
> > > karagian at cs.utwente.nl;
> > > >slblake at petri-meat.com { > Cc: pcn at ietf.org { > 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:karagian at cs.utwente.nl] { > {
> > > >Sent: 27 August 2008 11:37 { To: Eardley,PL,Philip,CXR9 R; { >
> > > >slblake at petri-meat.com { Cc: pcn at ietf.org { 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 defnts. 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
> > >
> > > At 13:03 27/08/2008, philip.eardley at bt.com wrote:
> > > >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:karagian at cs.utwente.nl]
> > > { Sent: 27
> > > >August 2008 12:56 { To: Eardley,PL,Philip,CXR9 R;
> > > >slblake at petri-meat.com { Cc: pcn at ietf.org { 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: philip.eardley at bt.com
> [mailto:philip.eardley at bt.com] { >
> > > >Sent: woensdag 27 augustus 2008 13:35 { > To:
> > > karagian at cs.utwente.nl;
> > > >slblake at petri-meat.com { > Cc: pcn at ietf.org { > 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:karagian at cs.utwente.nl] { > {
> > > >Sent: 27 August 2008 11:37 { To: Eardley,PL,Philip,CXR9 R; { >
> > > >slblake at petri-meat.com { Cc: pcn at ietf.org { 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:inition:
> > > >{ > {
> > > >{ > { "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: philip.eardley at bt.com { >
> > > >[mailto:philip.eardley at bt.com] { > Sent: woensdag 27
> > > augustus { >
> > > >2008 11:31 { > To: karagian at cs.utwente.nl; { >
> > > slblake at petri-meat.com {
> > > >> Cc: pcn at ietf.org { > 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:karagian at cs.utwente.nl] { > { Sent: 27
> > > >August 2008 { >
> > > >09:41 { To: Eardley,PL,Philip,CXR9 R; { > { >
> > > slblake at petri-meat.com {
> > > >Cc: pcn at ietf.org { 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:
> > > >philip.eardley at bt.com { > { > [mailto:philip.eardley at bt.com] { >
> > > >Sent: woensdag 27 { >
> > > augustus { >
> > > >2008 10:20 { > To: karagian at cs.utwente.nl; { > { >
> > > >slblake at petri-meat.com { > Cc: pcn at ietf.org { > 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:
> > > >pcn-bounces at ietf.org { > { >
> [mailto:pcn-bounces at ietf.org] On { >
>
> > > >{ > {
> > > >{ > { "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: philip.eardley at bt.com { >
> > > >[mailto:philip.eardley at bt.com] { > Sent: woensdag 27
> > > augustus { >
> > > >2008 11:31 { > To: karagian at cs.utwente.nl; { >
> > > slblake at petri-meat.com {
> > > >> Cc: pcn at ietf.org { > 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:karagian at cs.utwente.nl] { > { Sent: 27
> > > >August 2008 { >
> > > >09:41 { To: Eardley,PL,Philip,CXR9 R; { > { >
> > > slblake at petri-meat.com {
> > > >Cc: pcn at ietf.org { 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:
> > > >philip.eardley at bt.com { > { > [mailto:philip.eardley at bt.com] { >
> > > >Sent: woensdag 27 { >
> > > augustus { >
> > > >2008 10:20 { > To: karagian at cs.utwente.nl; { > { >
> > > >slblake at petri-meat.com { > Cc: pcn at ietf.org { > 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:
> > > >pcn-bounces at ietf.org { > { >
> [mailto:pcn-bounces at ietf.org] On { >
> > > >Beh> > >Behalf Of { Georgios { > { > Karagiannis { Sent: 27 August
> > > 2008 08:54 {
> > > >> { To: 'Steven Blake'
> > > >{ > { > { > { Cc: pcn at ietf.org
> > > >{ > { > { > { Subject: Re: [PCN] PCN WG last call for {
> > { > { >
> > > >draft-ietf-pcn-architecture-05.txt
> > > >{ > { > { > {
> > > >{ > { > { > { Hi Steven
> > > >{ > { > { > {
> > > >{ > { > { > { > -----Original Message----- { > { > { > { >
> > > From: Steven
> > > >Blake { > [mailto:slblake at petri-meat.com] { { > > { > Sent:
> > > woensdag 27
> > > >{ > augustus 2008 6:18 { > To: Georgios { { > Karagiannis { > Cc:
> > > >{ > pcn at ietf.org { > 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:slblake at petri-meat.com] { { >
> > > { > > > >
> > > >Sent: dinsdag 26 { > augustus 2008 14:46 { > > > To:
> > > >{ > { > { > Georgios Karagiannis { > > > Cc: pcn at ietf.org {
> > > > > > { > {
> > > >> { > 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 { alf Of { Georgios { > { > Karagiannis { Sent: 27 August
> > > 2008 08:54 {
> > > >> { To: 'Steven Blake'
> > > >{ > { > { > { Cc: pcn at ietf.org
> > > >{ > { > { > { Subject: Re: [PCN] PCN WG last call for {
> > { > { >
> > > >draft-ietf-pcn-architecture-05.txt
> > > >{ > { > { > {
> > > >{ > { > { > { Hi Steven
> > > >{ > { > { > {
> > > >{ > { > { > { > -----Original Message----- { > { > { > { >
> > > From: Steven
> > > >Blake { > [mailto:slblake at petri-meat.com] { { > > { > Sent:
> > > woensdag 27
> > > >{ > augustus 2008 6:18 { > To: Georgios { { > Karagiannis { > Cc:
> > > >{ > pcn at ietf.org { > 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:slblake at petri-meat.com] { { >
> > > { > > > >
> > > >Sent: dinsdag 26 { > augustus 2008 14:46 { > > > To:
> > > >{ > { > { > Georgios Karagiannis { > > > Cc: pcn at ietf.org {
> > > > > > { > {
> > > >> { > 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
> >> to
> > > >{ { > bandwidth allocation { in a multipoint-to-point fashion.
> > > >{ > { > { > {
> > > >{ > { > { > { >
> > > >{ > { > { > { >
> > > >{ > { > { > { > Regards,
> > > >{ > { > { > { >
> > > >{ > { > { > { > // Steve
> > > >{ > { > { > { >
> > > >{ > { > { > {
> > > >{ > { > { > {
> > > >{ > { > { > { _______________________________________________
> > > >{ > { > { > { PCN mailing list
> > > >{ > { > { > { PCN at ietf.org
> > > >{ > { > { > { https://www.ietf.org/mailman/listinfo/pcn
> > > >{ > { > { >
> > > >{ > { > {
> > > >{ > { >
> > > >{ > {
> > > >{ >
> > > >{
> > > >
> > > >_______________________________________________
> > > >PCN mailing list
> > > >PCN at ietf.org
> > > >https://www.ietf.org/mailman/listinfo/pcn
> > >
> > > ______________________________________________________________
> > > ______________
> > > Bob Briscoe, <bob.briscoe at bt.com> Networks Research
> > > Centre, BT Research
> > > B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.
> > > +44 1473 645196
> > >
>
> ______________________________________________________________
> ______________
> Bob Briscoe, <bob.briscoe at bt.com> Networks Research
> Centre, BT Research
> B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.
> +44 1473 645196
>
_______________________________________________
PCN mailing list
PCN at ietf.org
https://www.ietf.org/mailman/listinfo/pcn
> >{ { > bandwidth allocation { in a multipoint-to-point fashion.
> > > >{ > { > { > {
> > > >{ > { > { > { >
> > > >{ > { > { > { >
> > > >{ > { > { > { > Regards,
> > > >{ > { > { > { >
> > > >{ > { > { > { > // Steve
> > > >{ > { > { > { >
> > > >{ > { > { > {
> > > >{ > { > { > {
> > > >{ > { > { > { _______________________________________________
> > > >{ > { > { > { PCN mailing list
> > > >{ > { > { > { PCN at ietf.org
> > > >{ > { > { > { https://www.ietf.org/mailman/listinfo/pcn
> > > >{ > { > { >
> > > >{ > { > {
> > > >{ > { >
> > > >{ > {
> > > >{ >
> > > >{
> > > >
> > > >_______________________________________________
> > > >PCN mailing list
> > > >PCN at ietf.org
> > > >https://www.ietf.org/mailman/listinfo/pcn
> > >
> > > ______________________________________________________________
> > > ______________
> > > Bob Briscoe, <bob.briscoe at bt.com> Networks Research
> > > Centre, BT Research
> > > B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.
> > > +44 1473 645196
> > >
>
> ______________________________________________________________
> ______________
> Bob Briscoe, <bob.briscoe at bt.com> Networks Research
> Centre, BT Research
> B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.
> +44 1473 645196
>
_______________________________________________
PCN mailing list
PCN at ietf.org
https://www.ietf.org/mailman/listinfo/pcn