Bulk Transport WG Meeting Tuesday, May 3, 2005 Attendees: Guy Almes Jeff Boote Eric Boyd Rich Carlson Les Cottrell Susan Evett (scribe) Yunhong Gu Injong Rhee Chester Ruszczyk (MIT) Steve Senger Stanislav Shalunov Dany Vandromme (GIP Renater) Call started at 6:05 p.m. EDT. Agenda New Working Group Status Review of Previous Action Items Stanislav reported that this is an `official' working group; the charter was modified to be called ``Bulk Transport'' and there are specifications as to what the group will NOT work on (to not cover areas already covered by the IETF and GGF). The chairs of the WG are Injong and Stanislav. 1. Review of Previous Action Items a. All: Review the draft API Steven sent out (v.6.) and get comments to Steven by Monday, 4/25; Steven to revise, as necessary, and get a revised document to Susan by Wednesday, 4/27. [Stas submitted the only coments; group should consider this a continuing action item.] b. Susan to make copies of the design paper and the final draft of the API for distribution at the Member Meeting. [done -- 100 copies of design doc/ 75 of the api and they are mostly gone] c. Susan and Lisong to research the legitimacy of Annals of Telecommunication by 4/20. [Group to wait for better-matching venue for the design paper publication.] With regards to item `c', the following discussion occurred: Stas suggested the PFLDnet special issue (on networks) they are pulling together. Injong mentioned IEEE Networks; Stas asked Guy for input. Guy considered a SIGCOMM workshop but that would take a lot of advance planning. He mentioned that, for SIGCOMM 2006 meeting (an ambitious target) he advocated a one-day workshop with a good fit of topic on the Wednesday of the week. There is a lot of competition to be the `issue' but it is an idea for the future. Injong and Stas agreed that a separate white paper for Networks (with the design document as a basis for the paper) would be appropriate; this would definitely require additional work. It could be submitted as a whitepaper to IEEE Networks (different paper). Injong suggested going for one paper and then aiming for the workshop with SIGCOMM (high risk/high payoff) -- COMNET will be issuing a call for papers sometime in June or July. Stas and Injong felt that this would be a good place to submit the paper. Stas called for a `last call' on the working group so that it could be published as working group document (equivalent to a TR). Injong will keep the group posted on the call for papers when it comes out. Stas has been working on code to do delay-based transfers -- Gu asked what algorithm is in use in the demo; a delay-based congestion control algorithm that is modulating (it increases the rate when delay is down and decreases the transmission rate when delay is increased). He noted that noise filtering is not robust and this is a very early prototype. Stas did an informal demo of his code. Injong: how are we going to develop the flow-based control algorithm -- are we working on it together or are folks proposing several options? Stas felt this is a good platform for experimentation. Rich asked if it was run-time parameters or configuration parameters? Stas hadn't thought about this -- he considered compile-time vs. run-time. He didn't think it would be productive to give users a tool that requires extensive tuning (and require them to know how to use/modify the tool). Rich agreed; he personally thought compile-time would be more useful but he didn't know if users would want to be able to modify it. Stas argued that, to be easily used, you need to have some preset knobs for specific circumstances. This mini-program was designed to show that it is possible to send packets quickly and measure delay well. Injong suggested that the group decide how to design and implement this, or someone has to design it and the group needs to agree upon it. Stas noted that we have the API specification, and a design document but we don't have a protocol specification. Injong felt that the group has been avoiding that challenging question -- it was the one question in his mind when the group was formed -- what is the algorithm to be used. Stas commented that it would be difficult to make that choice without experimentation. Guy said that it would be a good thing if the ultimate thing that emerged did so after appropriate experimentation. We don't know all the answers yet. Injong suggested that we consider existing research in this area as a starting point -- he suggested that we look at the UDT protocol developed by Gu/Bob Grossman (U-Ill). Stas felt that the group needed to consider that an object-oriented program might be difficult to use outside of an object-oriented area. Injong wanted to look at this as a starting point; the group should look at it to identify potential limitations. Question is: who to do it? Stas said that he's already started looking at the code; he'll take on further exploration of that path. He requested that Steven take a look at it from the PoV of his application/API. Stas brought up a few considerations (object-oriented design, threads, etc.) -- Injong noted that they were very technical issues. Injong also thought folks in the group should be sharing algorithms they thought should be considered. Stas felt that, were it not for IPR concerns, we could look into using FAST TCP protocols because it works well with what we are doing; Injong noted that FAST TCP has its own issues/problems. Injong suggested sending out a call-for-proposals; group could ask Steven Low if he had suggestions. Guy agreed that it was time to start the CFPs -- but include an IETF-like NoteWell statement that suggestions would be open for experimentation by the Working Group. Stas mentioned it might be possible to take the IETF NoteWell and use whatever portion was not `protected'. Guy felt that one benefit of this would be that, seeing the algorithms of the different TCP flavors would be that the group would be designing the protocol with full understanding of the algorithms that might need to hook in. Stas noted that there are some classes of protocols described in the design document (loss-based, delay-based, etc.). Injong suggested the group experiment with the UDT protocol; Stas said that we try to make things work, using existing protocols (algorithm/framework/etc) and changing them around to see what works. Injong suggested that Stas review UDT and, once he is satisfied, members of the group implement several options. Stas noted that, before the CFP goes out, the IPR / NoteWell materials should be researched. Jeff asked how the API corresponds to the decision to start with UDT; Stas said that the group has not made a decision to use it -- only a decision to look at it. Jeff noted that one of the criteria was that you be able to implement the draft API on top of whatever is selected as a starting point. ACTION ITEMS: a. All (except Stas and Steven): Review the draft API Steven sent out (http://transport.internet2.edu/transport-api-06.pdf) and get comments to Steven. b. Injong to track the COMNET call for papers and keep the group posted when a date has been published. c. Stas to further review UDT Protocol as a starting point -- Steven will also consider the protocol with reference to his application/API needs. d. Injong to draft the CFP (by end of May); Stas to research using a modified IETF-like NoteWell in re IPR issues and provide Injong with a researched IPR statement (by 5/13). e. Stas to send out `last call' for changes on the design document. Next call is at 12:00 p.m. on 13 May 2005 using the usual dial in numbers and pin (0111111). Meeting ended at 7:03 p.m. EDT.