Explicit Charging for
Multicast (ECMmmm...)
|
|
|
Jon Crowcroft, |
|
UCL@AdastralPark.biz |
|
http://www.cs.ucl.ac.uk/staff/jon/ |
|
jon@cs.ucl.ac.uk |
IP Multicast evolution in
IETF
|
|
|
|
SSM now flavour of month (lots of ISPs
“about to deploy”) |
|
sing source matches most compelling
applications extant (multisource apps can use multiple ssm groups, or a
server (hopefully fault tolerant/dual redundent - e.g. game) |
|
Works well with interdomain (lose
BGMP/MASC rubbish:-) and with emerging RMT solutions |
Multicast Transport
Evolution in IETF
|
|
|
|
RTP/RTSP done deal |
|
RMT: PGMcc + ALC |
|
sender adaption exactly as TCP |
|
receiver adaption by selection of
layer(s) |
|
Both use TCP eqn model for rate => |
|
can replace loss signal with ECN |
Two Rival Approaches
|
|
|
|
Sender Pays |
|
Why multicast (scaling video servers)? |
|
Why help ISP? |
|
What about receiver (ac)counting? |
|
What about unknown receiver set
sizes/distributions/distances? |
|
|
|
Receiver Pays |
|
What about benefit to other users? |
|
What about benefit to ISP? |
|
What about late joiners? |
|
etc etc |
|
|
Tristan Henderson’s
Approach
|
|
|
Suggest we model it as a mix |
|
Sender pays based on ingress rate and
... |
|
Receivers pay based in share - |
|
Estimate #of receivers periodically |
|
Period is based on statistics of type
of session (have lots of studies of games, movies, music “holding times”) http://www.cs.ucl.ac.uk/staff/t.henderson |
|
Assume there’s a pay per content too,
so sender already has feedback channel to count receivers - could be RTCP based or PGMcc or PIM-SSM
... |
A Mark, a Buck, a Frank
or a Yen?
|
|
|
|
Correct model for ECN setting for
multicast packet? |
|
IP Level (ECN bis) |
|
ECN is set (typically) by RED (c..f AF
work by Dina Papagiannaki at UCL/Sprint..) |
|
Equivalent for Multicast is to set ECN
at router at ingress to congested link, then: |
|
randomly select which branch to forward
the packet with ECN (i.e. clear for all other branches) |
Aha, Aha, Aha....Aha
|
|
|
|
Correct model for reacting to ECN in a
multicast packet? |
|
RMT Level (ECN ter) |
|
Single rate (PGMcc) Sender adaption -
requires feedback to sender - EXACTLY as TCP - each receiver gets marks and
wraps them around - will find same operating point as PGMcc with loss
feedback |
|
Multirate (ALC) receiver adaption -
each receiver chooses layers based on ECN |
...In a Rich Man’s World
|
|
|
|
so above scheme gives proportional
fairness... |
|
can use M3I model for pay per ECN unmodified |
|
notice that the overall traffic
adaption rate is slower |
|
But its slower for n unicasts anyhow,
so? |
|
includes a two-level model (content and
network costs) but no coupling (necessary-
unless you want to bundle) - just rx counting, which ISPs wanted
anyhow, and CDNs have to have |
Any Questions…
|
|
|
What would you pay? notice cost may not
be predictable - not just coz of congestion price, but now share (risk is
other people game:-) |
|
No problem: have a risk broker |
|
CDNP may carry risk (has statistics on
“popularity” of game,film,song...tristan’s stats... |
|
J L? |