1. Efficient Protocols for Massive Data Transport Sailesh Kumar

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

3. 3 - Sailesh Kumar - 9/13/2015 What’s wrong? n Traditional bandwidth fairness is OK for »Voice applications (VOIP) »Streaming media applications »Web-surfing »Telnet n 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 n Such applications care about finish time rather than the average bandwidth that they receive n Scheduling policies which minimizes traditional fairness metrics are good for such applications

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

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

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

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

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

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

10. 10 - Sailesh Kumar - 9/13/2015 Fast Transport Service Model n New service to enable fast data transport »Smaller average finish time n 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 n Before any new request is committed network computes available bandwidth n Once any new request is committed, appropriate bandwidth is allocated

11. 11 - Sailesh Kumar - 9/13/2015 Fast Transport Payment Model n Several payment models are possible n 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 n Such payment and service model appears more attractive than having leased lines

12. 12 - Sailesh Kumar - 9/13/2015 High Level Network Architecture Central Scheduler

13. 13 - Sailesh Kumar - 9/13/2015 High Level Network Architecture n Central scheduler is aware of the entire metanet topology n Each meta-link has a unique identity n Every host has unique identity (different one) n Whenever a session begins, it is assigned a unique label n 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. 14 - Sailesh Kumar - 9/13/2015 High Level Architecture n Session labels are cryptographically generated by the central scheduler »Hash on source and destination identifier and on the start and finish time duration n 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 n Session labels are valid only between ts and tf n Packets with invalid session labels are discarded

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

16. 16 - Sailesh Kumar - 9/13/2015 Central Scheduler Design n 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 n 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. 17 - Sailesh Kumar - 9/13/2015 High Level Network Architecture 1 2 3 4 5 6 8 7 9 10 11 Time1234567891011 0 1 2 3 4 Start time = 2 XXXX XXXX XXXX Start time = 1 Link 6 is busy from 2 to 3 XXXX XXXX XXXX

18. 18 - Sailesh Kumar - 9/13/2015 Design Concerns n No use of the file size information in determining the schedules n May not take the optimum routes »Appears to be a greedy routing policy n 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. 19 - Sailesh Kumar - 9/13/2015 Conclusion n A new network architecture with the objective of minimizing the average finish times n It appears to be a difficult problem n However, even the simplest first-come first-serve policy is likely to reduce the average finish times significantly