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

["Geib, Ruediger" <[e-mail]>]

Hi Anna,

using PCN (hopefully) allows to engineer a network to stay below a 
certain "PCN flow block ratio" and make sure by stopping 
admission, that even during times of likely network distortions 
(like single link/router failures) the QoS of admitted PCN 
flows remains as guaranteed by an SLA.

Briefly, it is trading flow blocking for a better performance 
of admitted flows under most common operational conditions.

Please note that Telekom's backbone network is dimensionsed 
with redundant capacity. It further fully supports DiffServ.

Regards,

Rudiger
 

|-----Original Message-----
|From: Anna Charny (acharny) [mailto:[e-mail]]
|Sent: Wednesday, October 24, 2007 5:39 PM
|To: Geib, Rudiger
|Cc: [e-mail]
|Subject: RE: [PCN] Architecture draft - probing section & general
|updates.
|
|
|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:[e-mail]] 
|> Sent: Wednesday, October 24, 2007 10:41 AM
|> To: Anna Charny (acharny)
|> Cc: [e-mail]
|> 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:[e-mail]]
|> |Sent: Wednesday, October 24, 2007 3:54 PM
|> |To: Geib, Rudiger; [e-mail]
|> |Cc: [e-mail]
|> |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:[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