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

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

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