70 likes | 79 Views
This presentation discusses the interconnect QoS business requirements, including managing risk of congestion, cost economics, and the importance of per-session reservations. It also explores different pricing models and the need for competitive differentiation based on generic equipment and systems standards.
E N D
interconnect QoS business requirements Bob Briscoe BT Group CTO
app trans net link phys context b-w cost, C £/bps C 1 B • selling QoS = managing risk of congestion • if no risk of congestion, can’t sell QoS • congestion risk always in access nets (cost economics of fan-out) • but small risk in cores/backbones (failures, anomalous demand) • + usual motherhood requirements • cheap, simple (v little margin for everyone’s shares) 0 0 pipe bandwidth, B /bps
interconnect QoS – business reqs I • retail models • broadband: per-session QoS, price discrimination per application • corporate: VPN (not the focus of this presentation) • but e2e QoS ≠ one e2e business model, as long as: • back pressure from pricing passes through • each domain can make its profit • per-session charge not necessary at interconnect • bulk charging sufficient at interconnect whatever the retail model • can spread risk of QoS failure rate over bulk interconnect contract
interconnect service requirements • per-session (or per-VPN) reservations needed across cores? • if large proportion of utilisation is PSTN replacement, VPN: yes • for emergencies, re-routes, failures: yes • need reservation behaviournot nec.mechanism in cores • isn’t over-provisioning/diffserv sufficient? • PSTN replacement esp. flash crowds & emergencies: no(?) NB per session reservation per session reservation NA R1 ND S1 3 strict priority classes & congestion charging 7 Diffserv behaviours 7 Diffserv behaviours • Diffserv scheduling irrelevant on high speed links • can’t manage high speed networks at the congestion knee • getting there microseconds faster isn’t a business need • just strict priority for important traffic (reserved, emergency svcs etc)
sender or receiver pays? & denial of funds • two part tariff • sending domain pays C = ηX + λQ to r’cving domain per accounting period • X is capacity @ price η • Q is QoS/usage-related (volume, peak demand, congestion) @ price λ • both prices relatively fixed • usage related price λ ≥ 0 (safe against ‘denial of funds’) • any receiver contribution to usage through end to end clearinghouse • or bias fixed charges against receiving domain to compensate usage price,λ≥ 0 NB NA R1 ND S1 Capacity price,ηsigndepends on relative connectivity
interconnect QoS – business reqs II • competitive differentiation • not much but a little, for product evolution • based on generic equipment & systems standards
transp transp QoS QoS QoS QoS IP IP IP IP IP IP IP IP NB NA R1 ND S1 interconnect QoS business - summary • business model and/or service model • not nec. same along e2e path