[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PCN] MP2P aggregates

To: "Georgios Karagiannis" <karagian at cs.utwente.nl>
Subject: Re: [PCN] MP2P aggregates
From: Bob Briscoe <rbriscoe at jungle.bt.co.uk>
Date: Thu, 28 Aug 2008 16:06:39 +0100
Cc: pcn at ietf.org
Delivered-to: ietfarch-pcn-web-archive at core3.amsl.com
Delivered-to: pcn at core3.amsl.com
In-reply-to: <001d01c90907$a91beb10$810c5982 at dynamic.ewi.utwente.nl>
List-archive: <http://www.ietf.org/pipermail/pcn>
List-help: <mailto:pcn-request@ietf.org?subject=help>
List-id: PCN WG list <pcn.ietf.org>
List-post: <mailto:pcn@ietf.org>
List-subscribe: <https://www.ietf.org/mailman/listinfo/pcn>, <mailto:pcn-request@ietf.org?subject=subscribe>
List-unsubscribe: <https://www.ietf.org/mailman/listinfo/pcn>, <mailto:pcn-request@ietf.org?subject=unsubscribe>
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>
Sender: pcn-bounces at ietf.org

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 
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


>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 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 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: 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 { >
> > >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 { > 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

Follow-Ups:
- Re: [PCN] MP2P aggregates
  - From: Georgios Karagiannis

References:
- Re: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt
  - From: Georgios Karagiannis
- Re: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt
  - From: philip.eardley
- Re: [PCN] MP2P aggregates (was: PCN WG last call for draft-ietf-pcn-architecture-05.txt)
  - From: Bob Briscoe
- Re: [PCN] MP2P aggregates (was: PCN WG last call for draft-ietf-pcn-architecture-05.txt)
  - From: Georgios Karagiannis

Prev by Date: Re: [PCN] Request for clarification of Other and priority traffic - seedraft-eardley-pcn-marking-behaviour-01
Next by Date: Re: [PCN] MP2P aggregates
Previous by thread: Re: [PCN] MP2P aggregates (was: PCN WG last call for draft-ietf-pcn-architecture-05.txt)
Next by thread: Re: [PCN] MP2P aggregates
Index(es):
- Date
- Thread