RE: [PCN] Architecture draft

Hi Ruediger,

Thank you - that is very important information.  But may I ask why,
under these circumstances, one would want to use PCN at all?  PCN seems
to have the benefit of working in cases when the network is NOT well
provisioned for any reason (e.g. under the set of failures that are not
provisioned, or when traffic martix differs from the one "predicted" for
dimentioning?  So what is the motivation to go beyond the current
(PCN-free) environment, if we define away those
"not-so-well-dimentioned" circumstances as  being of no interest?

Thank you,
Anna 

> -----Original Message-----
> From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] 
> Sent: Wednesday, October 24, 2007 10:41 AM
> To: Anna Charny (acharny)
> Cc: pcn@ietf.org
> Subject: RE: [PCN] Architecture draft - probing section & 
> general updates.
> 
> Hi Anna,
> 
> one more remark on your question 4) would be, that Deutsche Telekom
> - to the extent I'm aware of it - does not plan her network 
> to provide QoS also during massive failures or flash crowds. 
> To the best of my knowledge, also consumer organisations rank 
> our IP network as the best or at least one of the best in Germany. 
> It is dimensioned to cope with probable failures and 
> forseeable traffic developments. I doubt that any carrier 
> acting in a highly competitive market, possibly regulated in 
> some parts, intends to invest heavily into his network to 
> provide QoS also under very exceptional operational 
> conditions. Especially, if a solution working under normal 
> operational conditions was significantly cheaper or faster 
> and easier to deploy.
> 
> Regards,
> 
> Rudiger
> 
> |-----Original Message-----
> |From: Anna Charny (acharny) [mailto:acharny@cisco.com]
> |Sent: Wednesday, October 24, 2007 3:54 PM
> |To: Geib, Rudiger; babiarz@nortel.com
> |Cc: pcn@ietf.org
> |Subject: RE: [PCN] Architecture draft - probing section & general 
> |updates.
> |
> |
> |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:Ruediger.Geib@t-systems.com]
> |> Sent: Wednesday, October 24, 2007 3:04 AM
> |> To: babiarz@nortel.com
> |> Cc: pcn@ietf.org
> |> 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:babiarz@nortel.com]
> |> |Sent: Tuesday, October 23, 2007 6:22 PM
> |> |To: Geib, Rudiger; philip.eardley@bt.com
> |> |Cc: pcn@ietf.org
> |> |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:babiarz@nortel.com
> |> |Telephone:613-763-6098
> |> |
> |> |-----Original Message-----
> |> |From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]
> |> |Sent: October 23, 2007 4:19 AM
> |> |To: philip.eardley@bt.com
> |> |Cc: pcn@ietf.org
> |> |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
> |> |PCN@ietf.org
> |> |https://www1.ietf.org/mailman/listinfo/pcn
> |> |
> |> 
> |> 
> |> _______________________________________________
> |> PCN mailing list
> |> PCN@ietf.org
> |> https://www1.ietf.org/mailman/listinfo/pcn
> |> 
> |
> 

_______________________________________________
PCN mailing list
PCN@ietf.org
https://www1.ietf.org/mailman/listinfo/pcn

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