February 16, 2005


SPEAKERS:
Stanislav Shalunov, Internet2 [PDF]
Steven Senger, University of Wisconsin-La Crosse

Stanislav Shalunov gave a presentation, in conjunction with Steven Senger, on the development of a new bulk file transfer protocol. SS felt that his would be the ‘killer app’ for this community – wide range of research projects and applications need to transfer extremely large bulk files over long distances.

He gave an overview of the problems that are encountered by applications (such as the one that Steven will be describing); the ‘wizard gap’ is getting ever wider – the researcher who has access to a network expert to tweak the application or equipment sees significantly better performance than the average user can ever hope to achieve.

Conventional TCP has a series of fundamental problems (unstable for high-speed networks, too sensitive to non-congestive packet loss, and buffer provisioning problems) and implementation problems (buffers are far too small – which limits the cross-country RTT to 7.5 Mbps on the largest of the ‘shipped’ buffers – and there is no provision for automatic buffer increases). Interactive applications that encounter changes in delay (based on congestion) go from acceptable to unusable. Remedies for these maladies run from invasive to extremely invasive; this includes tuning (buffers, window scaling, etc.) and using multiple streams.

Stanislav reported on the Internet2 effort to develop a transport tool – he listed the requirements (which included high performance, end-to-end, and no router modifications). A group of interested parties have been holding weekly conference calls to develop the design and write the draft paper. He reported that the draft design space document was available (in hard copy on the registration desk or at http://www.internet2.edu/~shalunov/transport/transport-design-space-07.pdf ). The document specifies the design requirements, which include explicit vs. implicit signaling, kernel vs. user-space, protocol features, window vs. rate-based, TCP compatible vs. TCP-friendly, (get slide).

He reviewed the current ideas that the group has developed regarding the design. This focuses on a portable, easy to use feature so it must be user-space with UDP, implicit congestion signaling, delay -based with fallback to loss-based, and state at receiver not at sender. The purpose of this talk is to get feedback, encourage involvement in the group, and ensure that user needs are heard before the design is finalized.

Steven Senger discussed the needs of his application – ImmSeg – which requires interactive bulk multimedia transfer, for which TCP is not suitable. Because the end user is visualizing volumetric data sets (such as for VHP), stereoscopic ray-cast image, that is haptically-enabled segmentation tools. The user has continuous control of the the remote computation; it exploits the user’s expert interpretive knowledge. Originally, the application was developed in 1997 at NASA Ames; Steven modified it in 2000 for use at the University of Wisconsin. He showed a stereoscopic image in which specific pieces of the anatomy have been removed, layer by layer. This is a collaborative environment – the tool is real-time visualization. Steven provided a description of the modes of operation and visualization streams (pixel updates during user action, up to 30 Mbps per client, tolerates small loss, prefer reliable at the close of the action) and haptics stream (reflects changing segmentation on server, stream is a random sample, client retains last ½ second of data, and it is unreliable – heavily rate dependent). He noted that this particular application relies heavily

Q: I was pleased to read the paper (Connie Logg, SLAC) – do you plan to have a group of people to develop this protocol?
A: Yes.
Q: It would be useful to have some instrumentation that indicates what the current conditions are.
A: That is a good idea and it is not sufficiently addressed in the current design space. We will add this.

Q: In addition to doing bulk transfers with UDP-based user-space tool, one could use different TCP flavors for advanced control (such as HighSpeed TCP). Why do you lean towards a UDP tool? A: Ease of deployment, portability, and ability to use approved, stable, and running kernels are the main reasons.

C: Very interested in supporting your efforts. (Jorg Micheel, NLANR) We would be willing to work with you on this.

Q: Is this a transport control protocol – not a file transfer protocol?
A: Correct – though one of the primary applications would b e for bulk file transfer.
Q: Will the API tied to this protocol be similar to the API used for sockets so that it will be easy to implement?
A: Yes.

Q: Have you done any research on the overhead on packet interrupts?
A: This is a very valid concern – each context switch on a modern machine takes a microsecond or 2; but our calculations show that, with a modern CPU / network, this may be expensive but it is acceptable (there is sufficient CPU available).
Q: Is this for Gig or 10 Gig?
A: If you are using it for 10 Gig, it is cutting edge and you need cutting edge CPU capability.