1 / 19

Efficient Protocols for Massive Data Transport

Efficient Protocols for Massive Data Transport. Sailesh Kumar. Present Transport Protocols. Fairness has been important in networks Competing flows get similar bandwidth Two primary components of fairness End-to-end fairness versus per link fairness TCP (end-to-end fairness)

xena-henry
Download Presentation

Efficient Protocols for Massive Data Transport

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. Efficient Protocols for Massive Data Transport Sailesh Kumar

  2. Present Transport Protocols • Fairness has been important in networks • Competing flows get similar bandwidth • Two primary components of fairness • End-to-end fairness versus per link fairness • TCP (end-to-end fairness) • Additive increase, multiplicative decrease • Fairness is defined with respect to the bottleneck link • Flow scheduling at the links (per link fairness) • Ideally, competing flows share the bottleneck using GPS • W2FQ is the packetized version of GPS • TCP/GPS scheduling enable total fairness

  3. What’s wrong? • Traditional bandwidth fairness is OK for • Voice applications (VOIP) • Streaming media applications • Web-surfing • Telnet • Not OK for • FTP • Large data transfer/web downloads • Mail (large attachments) • We do not care about the average bandwidth, we rather care about when the file has been completely transferred • Such applications care about finish time rather than the average bandwidth that they receive • Scheduling policies which minimizes traditional fairness metrics are good for such applications

  4. What should we do? • To minimize the average finish time • Send the files one after another • If there is a single bottleneck • Shortest job first will lead to the smallest average finish time • Moreover, no flow will suffer 10 f.t. = 10 f.t. = 10 3 bytes per second 10 f.t. = 11.6 15 Average finish time = 10.6

  5. What should we do? • To minimize the average finish time • Send the files one after another • If there is a single bottleneck • Shortest job first will lead to the smallest average finish time • Moreover, no flow will suffer 10 f.t. = 3.3 f.t. = 6.6 3 bytes per second 10 f.t. = 11.6 15 Average finish time = 7.6

  6. Multiple Bottlenecks 2 B/s • Problem becomes more complex when there are multiple bottlenecks • SJF: Flow 3 finished after when it finishes in GPS • What should we do???? 10 f.t. = 5 f.t. = 5 3 bytes per second 10 f.t. = 12.5 15 Average finish time = 7.5

  7. What should we do? 2 B/s 10 f.t. = 10 f.t. = 10 3 bytes per second 10 f.t. = 11.6 In this region, we can rearrange red/green flow 15 GPS schedule Pink link is bottleneck Green link is bottleneck

  8. What should we do? 2 B/s 10 f.t. = 5 f.t. = 10 3 bytes per second 10 f.t. = 11.6 In this region, we can rearrange red/green flow 15

  9. High Level Algorithm • Computed GPS schedule for all competing flows • Use min-max schedule • Mark all time events when the bottleneck changes • Call the ith such time event tbi • Between any two periods tbi and tbj • Find all flows which finishes their transmission • Rearrange according to SJF policy if it does not increase their finish times • The above algorithm ensures that none of the flows finish after their finish time in a GPS schedule • The algorithm also ensures that the average finish time is minimized • Proof in the paper

  10. Fast Transport Service Model • New service to enable fast data transport • Smaller average finish time • Hosts can request four kinds of services from the network to transfer files • High priority service • Transfer ASAP, scheduler notifies the earliest possible time • Periodic service • Transfer once per day, at start time ts, must finish before next day • Low priority service • Transfer whenever extra bandwidth is available • Scheduled service • Transfer once starting at time ts and must finish before time tf • Before any new request is committed network computes available bandwidth • Once any new request is committed, appropriate bandwidth is allocated

  11. Fast Transport Payment Model • Several payment models are possible • Charge based upon • The service type (one of the four types) • Amount of data transferred • Average finish time seen • Thus the unfortunate flows will not crib anymore • Such payment and service model appears more attractive than having leased lines

  12. High Level Network Architecture Central Scheduler

  13. High Level Network Architecture • Central scheduler is aware of the entire metanet topology • Each meta-link has a unique identity • Every host has unique identity (different one) • Whenever a session begins, it is assigned a unique label • Use source routing coupled with label switching • First packet contains the entire route information • All meta-link identifiers • It also contains the session label • While this packet is routed, meta-routers update the forwarding table (maps session label to the next meta-link) • Subsequent packets only contain the session label • these are routed with the above forwarding table

  14. High Level Architecture • Session labels are cryptographically generated by the central scheduler • Hash on source and destination identifier and on the start and finish time duration • In order to obtain a session label, host software contacts central scheduler • Provides • Its identity • Number of bytes it has to send, b • Identity of the destination • Intended start time, ts • Receives • Projected finish time of the transfer, tf • Session labels are valid only between ts and tf • Packets with invalid session labels are discarded

  15. Transport Mechanism • Hosts transmit data at constant bit rate • Token bucket scheduling • Rates are assigned by the central scheduler • Thus no congestion control needed in the network • Scheduling ensures that no link will be congested • For loss recovery packets will simply be retransmitted • Packets will be marked with sequence numbers as in TCP

  16. Central Scheduler Design • Finding optimum schedule appears to be a difficult problem when there are multiple bottlenecks • Our algorithm finds optimum schedule for static requests • When requests dynamically arrive and leave the system, it is not trivial • Moreover, with the four different service types, it becomes even more difficult • Proposal: • First come first serve • Scheduler keeps track of available bandwidth at all meta-links • For high priority requests, compute route with the maximum available bandwidth available in the nearest future • Allocate bandwidth on those links for the desired duration • Schedule low priority requests (soft finish time) in SJF manner

  17. High Level Network Architecture Link 6 is busy from 2 to 3 9 1 5 Start time = 2 8 6 2 4 10 7 Start time = 1 11 3 X X X X X X X X X X X X

  18. Design Concerns • No use of the file size information in determining the schedules • May not take the optimum routes • Appears to be a greedy routing policy • The central problem is that once the network commits something to a host, it can not change it • Thus if some time later, a new request arrives whose transfer size is much smaller, it will not benefit

  19. Conclusion • A new network architecture with the objective of minimizing the average finish times • It appears to be a difficult problem • However, even the simplest first-come first-serve policy is likely to reduce the average finish times significantly

More Related