An Architecture for Internet Data Transfer

1
An Architecture for Internet Data Transfer

• Offence by
• Aaron Ballew
• Sagar Vemuri

2
Stated Problems

• Inappropriate for real-time communication
• telnet, teleconferencing
• DOT uses batch transfer technique
• Imposes latency for time-critical apps
• Does not work well for communication which is
  primary control data
• Instant messaging

3
Fundamental Motivation

• For a generic service, DOT already carves out a
  subset of application traffic (wont work for
  x,y,z).
• Then even for file transfers, it only works well
  for large transfers that can amortize the
  overhead of hashing, handshaking, control, etc.
• For such a specific audience, how is this
  generic?

4
Handshaking

• DOT begins transferring data only after both
  sending and receiving apps are ready.
• What if one of them is not ready?
• Overhead of hashes, long negotiation/handshake.
• Cant handshake over portable storage, and the
  authors are big supporters of portable storage.
• If one hashing algorithm is supported by the
  sender but not by the receiver
• How is hashing accomplished?

5
Security

• Increases security risk by having all the data at
  one place
• Privacy issues
• Inspecting application data
• Doesnt work if encryption is required
• Currently, data transfer depends on the
  application protocol implementation
• But in DOT, the data transfer is application
  independent
• Hence much easier to gain access to all the data

6
Cache Issues

• Newer data might overwrite the cached data at the
  receiver end before the receiver reads it
• No mention about the requirement for the size of
  cache
• In case of session break, GTC caches. How to
  time-out if it doesnt reconnect? Who says this
  data can just be retained in cache?

7
Hints

• Hints about where to find data.
• Why doesnt sender just tell where to find data?
  
• How does sender know where to find data?

8
Deployment

• How are dynamically generated objects
  transferred?
• Need to modify all the existing applications to
  support DOT, i.e. make application requests look
  like RPCs.
• No mention of deployment anywhere
• Is incremental deployment possible?
• Requires that new applications be written to use
  this.

9
Incentive to use

• If generic service chooses TCP anyway, why not
  just use TCP?
• Isnt this just adding a new layer to the
  OSI/TCP/IP model?
• Is there any enforcement to use this?
• Why would anyone use it when they could just
  purpose-build and optimize for their app?
• They say it promotes innovation, but why would
  industry implement this?

10
Multipath

• For multipath, why 10 requests per sub-plugin?
• How to choose and balance on paths?
• How to deal with out of order data?
• How to reallocate when a sub-path fails? They
  give one sentence.
• What if there is more than one hop in each
  sub-path? How is GTC supposed to balance w/o any
  feedback info? Leave this to routing.

11
Evaluation

• Evaluation purposely ignores small transfers,
  knowing that the system performs worse under that
  case (4kB vs. 40kB).
• Eval focuses only on means. Need to know more
  about the statistics, namely the variance. Mean
  of 10 trials, mean of 255MB, etc. Assuming
  linear performance scale.
• 10 trials is a small sample set.
• Says DOT saves 20 of msg bytes, where is this
  from? Graph shows 14.

12
Conclusion

• Not generic enough.
• Too many major problems identified (by the
  authors) and not addressed.
• No incentive to use it.
• Significance of improvements are unimpressive.