1 / 18

Enhancing End-to-End Service with Bill-Pay: A Solution for ISP Payments and Quality

This paper discusses the innovative Bill-Pay mechanism that enables end users to make micropayments to intermediate ISPs, thereby improving end-to-end service delivery. By allowing payments tied to service quality, users can prioritize their traffic, addressing challenges such as congestion and ensuring better performance. The authors explore potential applications, the operational framework of Bill-Pay, and the implications for ISPs and users, alongside addressing critical concerns such as security and pricing structures.

brede
Télécharger la présentation

Enhancing End-to-End Service with Bill-Pay: A Solution for ISP Payments and Quality

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Achieving good end-to-end service using Bill-Pay Cristian Estan, Aditya Akella, Suman Banerjee Univ. of Wisconsin - Madison

  2. QoS today • ISPs offer SLAs to customers • SLAs do not apply for multi-ISP paths • Core problem: end users cannot pay intermediate ISPs • Bill-Pay allows such payments

  3. Overview • What is the Bill-Pay mechanism? • What can we build on top of it? • What were they thinking?

  4. 19 10 2 9 20 6 7 1 -14 8 1 Bill-Pay example ISP Y ISP X ISP Z B A

  5. Core ideas • Nanopayments associated with packets • Sender sets initial nanopayment • Easy-to-enforce local bilateral contract • Upstream must pay (at the end of month) • Downstream has no contractual obligation • Downstream has incentive to provide good service, pay next ISP • Sender has some control over path

  6. 28 0 16 24 32 Nanopayment amount Pathlen OADcnt ISP OAD ISP identifier (AS number) Available alternatives Choice Pathlen User OAD OADcnt ISP identifier (AS number) Undesirable alternatives Choice Protocol mechanics • ISPs offer a few “opaque alternatives” • Can mean: next hop, diffserv class, internal route • Sender OAD = desired treatment by an ISP

  7. Overview • What is the Bill-Pay mechanism? • What can we build on top of it? • What were they thinking?

  8. Solutions using Bill-Pay • Better e2e delay, throughput, loss rate • Handling floods and flash crowds • The users valuing the service the most get through, the other traffic is dropped • Micropayments (between any 2 hosts) • Requiring micropayments with emails will kill the spammers’ business model

  9. Overview • What is the Bill-Pay mechanism? • What can we build on top of it? • What were they thinking?

  10. ISPs will jack up prices! • Justifiable fees • Fixed per byte/per packet • Congestion pricing • Avoiding “unjustifiable” fees • If there is path diversity, users will direct traffic through cheaper paths • With chokepoints/unregulated monopolies, users pay a lot even with flat prices

  11. Too costly for ISPs to deploy! • Potential benefits are huge • Users in industrialized countries spend on average extra $10/year → $10 billion/year • Backbones running at higher link utilization → savings of ?? billions/year • Skimming 1% of all micropayments (<$5) in the U.S. → $10 billion/year

  12. Mapping is expensive! • Can share information w/ other hosts on the same campus (or p2p network) • Can use non-critical traffic (instead of probes) to measure new paths • Typical AS path length is 3 • Sender does not need full information • One good path is enough

  13. Hackers will steal the money! • Hijack computer, leak nanopayments, get money at the end of the month • Solution: “digital secretary” running on trusted hardware must certify packets • Network verifies signatures at edge • Limited functionality → unhackable • Increases cost of solution

  14. Hard to judge a packet’s worth! • Can talk to the user directly • Trade-off between intrusiveness and cost of guessing wrong • If user (or digital secretary) cannot tell apart important traffic from excessive junk, he cannot expect quality service!

  15. Open questions • Optimal behavior for rational ISP? • How to “modulate” nanopayments? • Interactions with congestion control? • Effect on network topology? • Path selection and stability?

  16. The end Fire at will!

  17. We hate usage-based pricing! • Not if we get a good deal! • User can refuse to add nanopayments

  18. Load-aware routes = instability • IP routing: all packets to a destination take the same path → flapping • Bill-Pay: senders make desynchronized decisions → load balancing

More Related