Efficient protocols for massive data transport
Download
1 / 19

Efficient Protocols for Massive Data Transport - PowerPoint PPT Presentation


  • 71 Views
  • Uploaded on

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)

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Efficient Protocols for Massive Data Transport' - xena-henry


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

Present transport protocols
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


What s wrong
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


What should we do
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


What should we do1
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


Multiple bottlenecks
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


What should we do2
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


What should we do3
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


High level algorithm
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


Fast transport service model
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


Fast transport payment model
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



High level network architecture1
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


High level architecture
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


Transport mechanism
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


Central scheduler design
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


High level network architecture2
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


Design concerns
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


Conclusion
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


ad