RE: [PCN] Architecture draft - probing section & general updates.

["Anna Charny (acharny)" <[e-mail]>]

Hi Lars,

I have a question and a point:

1) Question:  

You say:

> I see PCN as being complementary to traditional, hop-by-hop 
> signaled QoS reservation mechanisms. These mechanisms already 
> cover scenarios with low-aggregation levels well. They tend 
> to break down for high traffic volumes, which is exactly 
> where I'd expect PCN to be the most attractive. 
 
Why do you say that aggregate hop-by-hop reservation mechanisms tend to
break at high traffic volumes? 

2) Point:

You say: 

>In other 
> words, because using PCN in low-aggregation scenarios means 
> that probing is required, with the already-discussed 
> complexities, 

I would ask the question in two parts:

   - is it important for a mechanism to work well when there is a small
number (but greater than 1) of ingress-egress flows for a large number
of ingress-egress pairs.  Note that this is not necessarily a question
about probing, but that of performance of an algorithm on low
ingress-egress aggregation levels (this is because once the first flow
is accepted, it provides the necessary state for admission of future
flows, and does it reasonably well at least for some of the proposed
algorithms).

   - should the WG consider the case when expected number of flows on
very large number of ingress-egress aggregates sharing a bottleneck has
on the order of *one* flow.  Note that this is the case when probing
might be needed.

Anna  

> -----Original Message-----
> From: Lars Eggert [mailto:[e-mail]] 
> Sent: Friday, October 19, 2007 10:19 AM
> To: Anna Charny (acharny)
> Cc: Hancock, Robert; [e-mail]; [e-mail]
> Subject: Re: [PCN] Architecture draft - probing section & 
> general updates.
> 
> Hi,
> 
> On 2007-10-19, at 16:23, ext Anna Charny (acharny) wrote:
> > Actually,  I did not mean low aggregation *at the 
> bottleneck*, which 
> > is what the charter seems to restrict.  Rather I meant the 
> case when 
> > the bottleneck has high aggregation, but traffic on that bottleneck 
> > comes from a large number of ingress-egress pairs, each having very 
> > low aggregation levels.  I believe technically the charter does put 
> > any explicit restrictions on the scope for ingress-egress 
> aggregation.
> 
> thanks for teasing these two issues apart. I had been under 
> the assumption that one would come with the other, but you're 
> correct that they can be unrelated.
> 
> It was the intent of the charter to initially restrict PCN to 
> scenarios with significant levels of multiplexing, so that 
> simple, statistical measures are effective. So I'd argue that 
> although the current charter text isn't explicit about 
> ingress-egress-pair aggregation levels, it was written under 
> the assumption that they'd be significant.
> 
> That said, I do agree with you that it would be good to come 
> to an explicit agreement on this within the WG.
> 
> > Perhaps the WG should consider whether it is reasonable to impose 
> > restrictions on the *ingress-egress* aggregation levels as 
> well.  An 
> > argument can be made that in practice a large number of 
> ingress-egress 
> > pairs may only have a few flows, even when the bottleneck 
> aggregations 
> > are large.
> >
> > The decision on whether low ingress-egress aggregation level is in 
> > scope seems to be important for choosing among the various 
> approaches 
> > proposed to the WG, as some of them are substantially more 
> sensitive 
> > to the low ingress-egress aggregations than others (e.g. single 
> > marking does not perform well at very low levels of 
> aggregation, as we 
> > showed at the last meeting).
> >
> > Perhaps an explicit discussion on the assumptions regarding the 
> > expected levels of ingress-egress aggregations is needed on 
> the list?
> >
> > Towards that discussion, my personal view is that in the long range 
> > ignoring low levels of ingress-egress aggregation levels 
> will severely 
> > limit the viability/usefulness of the technology.  However, 
> perhaps as 
> > an initial step it would be OK to assume moderate to high 
> aggregation 
> > levels, as long as a clear path is visible on how to address low
> > aggregations in the future within the scope of defined behaviors.   
> > But I
> > think it is important to have a clear consensus on this point.
> 
> Agreed.
> 
> I've stated my reasons for wanting PCN to focus on 
> high-aggregation scenarios in previous emails. Let me add one 
> additional argument:
> 
> I see PCN as being complementary to traditional, hop-by-hop 
> signaled QoS reservation mechanisms. These mechanisms already 
> cover scenarios with low-aggregation levels well. They tend 
> to break down for high traffic volumes, which is exactly 
> where I'd expect PCN to be the most attractive. In other 
> words, because using PCN in low-aggregation scenarios means 
> that probing is required, with the already-discussed 
> complexities, delays and overheads, traditional QoS 
> mechanisms become attractive. Yes, signaled QoS mechanisms 
> are more complex than PCN, but not much more complex than PCN 
> with a fully-worked out probing mechanism. Additionally, 
> signaled QoS setup results in a guarantee that a flow can be 
> sustained, while even with probing, PCN will only results in 
> an estimate on whether a flow can be sustained.
> 
> Lars 


_______________________________________________
PCN mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/pcn