Transport protocols and bulk file transfer

[stanislav shalunov <>]

                     Bulk Transport Protocol Call
                      Friday, December 10, 2004

Attendees:

        Larry Dunn
        Susan Evett (scribe)
        Yunhong Gu 
        Xinwei Hong
        Shawn McKee
        Injong Rhee
        Steven Senger
        Stanislav Shalunov
        Lisong Xu

Call started at 12:01 p.m. EST.


                                Agenda

        Action Items overview
        NSF NeTS proposal
        API Description
        Web100 Clarification

[Arabic numerals in brackets below indicate forward references to
action items grouped at the end of the minutes.]


                        Action Items Overview

Stanislav reviewed the action items collected from the previous call
and noted which ones are ongoing and which have been done.  He
double-checked that comments to the paper had been addressed to the
satisfaction of those who made them.  He has posted the revised
version. [1]


                          NSF NeTS proposal

He noted that Martin was going to talk about NETS proposal; because
Martin couldn't attend this call, if the group delays discussion of
the proposal until that time, it would not leave a lot of time for the
proposal.  Stanislav suggested that either the group postpone the
discussion until next week or the group should begin the discussion
via email.  Injong suggested that the discussion begin via email, so a
final decision could be made by the next meeting (2004-12-17). [2]


                           API Description

Steve gave a brief description -- a non-blocking I/O -- of the API.
Stanislav asked if you can break it up into blocks or a pointer.
Steve responded that you are given a pointer.  Stanislav asked what
the implementation does -- start a new process, a new thread?  Steve:
my understanding is that it just includes that space in the held
space; when the call is done, the space is released.  Stanislav asked
how does the delivery mechanism happen -- Steve thought a UDT person
could answer that.  With overlapped I/O, when an asynchronous send
call is issued, how does the data get delivered?  How does it get the
running context?  Gu said it is a separate thread.  One thread for
data sending but a different I/O will be synchronized -- all the data
sent on one thread.

Steve polled the group -- there is enough interest in this to include
some form of it (non-blocking, but not necessarily asynchronous).
Injong said there are several ways to implement this but it would be a
good feature to include.  Steve expressed concern about sockets --
what to do about minimizing buffer copying.  Steve asked for
suggestions; Stanislav listed some standard approaches (on receive
side, specify some page alignment so that page flipping can be made to
work later with a kernel modification).  Steve plans to include send
file/receive file calls.  Lots of focus on ways to respect message
boundaries in the send/receive packets.  He asked if that was in line
with what others were looking for; Injong felt it would be useful but
that not necessary.  Larry noted that this may need to be revisited if
the Path MTU changes underneath you.  Stanislav felt that, for packet
size, we should go with the new standards work on PMTUD; Larry asked
Steve if adjusting/modifying packet size/MTU during transfer is going
to be addressed.  Steve said he hadn't thought about that problem.
You could return an error or you could get a message telling you to
retest (send message/receive message of the current MTU size).  Steve
suggested that we have a way to query the current MTU size; Larry was
concerned that this would add a lot of complexity but he wasn't sure
how the tradeoff would work.  Steve felt that he could go either way
with his applications -- the second option would complicate the
implementation.

Injong felt the send message/receive message with additional API to
find out the current MTU size would be sufficient for most uses.  This
is driven by performance of an application vs. because an application
DEPENDS upon it.

Steve addressed having a packet remain in a queue until it can be
delivered or a way to tell the sender not to resend data when there is
still data is in the queue; he asked if this was important to others.
Stanislav felt that this would be useful for voice and other similar
applications with a known delay budget.  Steve suggested ways to
inform the sender to completely resend data -- Stanislav was concerned
that this would turn into complete unreliability with window size
greater than 1 packet and constant supply of data.  He suggested
adding a call to `flush the queue' -- which could be used before
sending a new burst of data.  Steve was interested in having this work
with bursts that are experiencing loss.  Larry felt that Steve's
problem and his response were not descriptive of each other.  Steve
and Larry will start a discussion of the use on the email list. [4]
Steve cited an interesting RFC (SCTP) related to this, but was looking
for more information on partially reliable transport; Larry suggested
that he contact the authors of the RFC. [5]

Steve: Should this be written as a functional API?  Or
Object-Oriented?  Stanislav suggested functional -- easy to add a
wrapper around it to make it OO but hard if it starts out as OO to
make it usable for non-OO tools.


                         Web100 Clarification

Larry had suggested having some way for the user to interface with
Web100 (the UI part) -- gutil, you can clamp it onto a particular
stream and get lots of information.  It is in User-space; gutil, if
given some slight tweaks, could be directed where to look for
information (other than /proc).  Larry wasn't sure if this could be
used to reduce the number of UI's necessary.  Larry is seeing this as
an interface for troubleshooting tools.  He queried what folks thought
would be useful to tell users: rate, etc.  Stanislav noted that this
would be 6-12 things; but Web100 is over 100 things -- when Matt
Mathis needs to find a Web100 variable, he needs to use a search
function in Emacs; but, since Web100 is well-thought-out by
troubleshooting experts, perhaps the group can take some variables
from there.  Stanislav suggested a possible sub-set of Web100 but he
wasn't sure how to get at it (/proc wouldn't work; maybe a Unix
socket?  Does Web100 have a standard way of exporting through those?);
Larry suggested that, if we wanted to pursue this, we could get Matt
M. and several other people into the discussion.  Stanislav asked if
this was a critical portion or something to keep in mind?  Larry
thought this was a keep in mind -- not worth slowing down the project
for this.


ACTION ITEMS FROM THIS CALL:

1. ACTION ITEM: All to look at the requirements section of the
   document to ensure it captures the intent of the group.

2. ACTION ITEM: Stanislav to initiate an email discussion in re NeTS.

3. ACTION ITEM: Steve to include several items to the API based on
   group consensus.

4. ACTION ITEM: Larry and Steve will start a discussion on the list
   about how long a packet can remain in the queue before flushing
   should occur.

5. ACTION ITEM: Steve to contact the authors of the SCTP RFC to see if
   new schemes of partially reliable transport (other than
   time-budget-based) are being developed.

Next call is at the same time (noon US/Eastern) on 2004-12-17.

Call ended at 12:57 pm EST.

-- 
Stanislav Shalunov              http://www.internet2.edu/~shalunov/

Antibiotics comprise 2% of cow feed in U.S. feedlots, by weight.