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

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

Hi all,

I think it boils down to a set of questions below.  If anyone has any
direct data regarding real-time traffic from today's Diffserv networks
(or any futuire projections) that can help answer those questions, itr
would help resolve the probing discussion.

1) is it a common occurrence in todays Diffserv networks (say using EF
to support real-time traffic) that a large number of ingress-egress EF
aggregates have just 1-2 flows?  [I do not have direct data but from
many incidental pieces of information I think the answer may be yes]

2) Is it reasonable to assume that when video becomes widespread, many
ingress-egress aggregates might have just 1 video flow?  [I do not see
why this cannot be the case]

3) Even if many ingress-egress aggregates are small, is it a common
occurrence that on a bottleneck link inside the network a large portion
of the bottleneck bandwidth is taken by those small ingress-egress
aggregates? 
[It seems a more expected case is when the bottleneck is shared by large
and small aggregates, and the large aggregates take a fair amount of
bandwidth. It this case, under "normal circumstances" when the demand on
the bottleneck does not drastically exceed the configured admission
rate, admission control will likely resolve the pre-congestion at the
expence of the large aggregates.]

4) Are there realistic circumstances (flash crowds or massive failures
lasting for some time?) when the load on the bottleneck of small
aggregates alone might cause substantial overload?  (and if so, should
we attempt to address these cases for admission or just rely on
termination?

Anna 

 

> -----Original Message-----
> From: Geib, Ruediger [mailto:[e-mail]] 
> Sent: Wednesday, October 24, 2007 3:04 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: RE: [PCN] Architecture draft - probing section & 
> general updates.
> 
> Joe,
> 
> my perception is, that probing may be useful, once there is 
> pre-congestion. In a situation without a single admitted flow 
> between an ingress and an egress, if neither ingress node nor 
> egress node have any indication of pre-congestion on any of 
> the links crossed by the PCN flows passing through them, 
> there's with high probability no need to probe, I'd assume. I 
> don't do simulations and would like to invite those 
> simulating to come up with cases where this assumption is wrong.
> 
> I'd further propose to collect information from providers on 
> the probability of the event you describe. 
> 
> Regards, 
> 
> Rudiger
> 
> |-----Original Message-----
> |From: Jozef Babiarz [mailto:[e-mail]]
> |Sent: Tuesday, October 23, 2007 6:22 PM
> |To: Geib, Rudiger; [e-mail]
> |Cc: [e-mail]
> |Subject: RE: [PCN] Architecture draft - probing section & general 
> |updates.
> |
> |
> |Ruediger, the issue is not addition of one more flow into 
> the link that 
> |is experiencing (pre-)congestion level for admission but potentially 
> |hundreds of new ingress-egress aggregates that have not been 
> |established passing through the link.
> |
> |Regards, Joe
> |email:[e-mail]
> |Telephone:[phone]
> |
> |-----Original Message-----
> |From: Geib, Ruediger [mailto:[e-mail]]
> |Sent: October 23, 2007 4:19 AM
> |To: [e-mail]
> |Cc: [e-mail]
> |Subject: RE: [PCN] Architecture draft - probing section & general 
> |updates.
> |
> |Phil,
> |
> |I appreciate that probing is optional. I understand that to 
> mean that 
> |standardisation allows to operate PCN within a domain 
> without having to 
> |support any probing functionality.
> |
> |There may be operational conditions, when probing makes 
> sense. This may 
> |be the case, if the number of multiplexed flows is at the 
> lower bound 
> |of the range where statistical multiplexing can be applied 
> on any link 
> |and the number of possible ingress to egress relations passing this 
> |link is big enough to lead to (pre-)congestion by admission 
> of a single 
> |flow with a reasonable probability. I don't want to stop people from 
> |working on this issue, but I'd favour PCN to finish standards for an 
> |operational environment where the probability of a single 
> admitted flow 
> |causing congestion on a link is extremly low.
> |
> |Regards,
> |
> |Rudiger
> |
> |
> |_______________________________________________
> |PCN mailing list
> |[e-mail]
> |https://www1.ietf.org/mailman/listinfo/pcn
> |
> 
> 
> _______________________________________________
> PCN mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/pcn
> 


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