efficient protocols for massive data transport n.
Download
Skip this Video
Download Presentation
Efficient Protocols for Massive Data Transport

Loading in 2 Seconds...

play fullscreen
1 / 19

Efficient Protocols for Massive Data Transport - PowerPoint PPT Presentation


  • 72 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


Download Now 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