Transport protocols and bulk file transfer

[Larry Dunn <>]

Scott,
Sounds good- is swolff still doing CTO duty?
If so, please be sure to say "hi!" for me. ;-)

Larry
--

On Sep 30, 2012, at 4:26 PM, Scott Brim wrote:

> FYI I'm going to mention this idea in the CTO update on Tuesday.
> 
> ... Scott
> 
> On 08/16/12 17:57, Larry Dunn allegedly wrote:
>> Colleagues,
>> On our last call (~2 months ago),
>> I promised to write up the stray thoughts I had
>> re: seeing if "the community" thought there was
>> value in bringing togther:
>> a. folks that write TCP stacks in workstations, and
>> b. folks taht do queuing algorithms in routers (per scott: +middleboxes), 
>> etc.
>> 
>> So, here's a draft of those thoughts.
>> We may/may_not choose to discuss tomorrow...
>> 
>>  *  The TCP congestion control and performance characterization
>>     community consists of at least two sets of researchers and
>>     implementers - those that develop queuing strategies for routers,
>>     and those that develop congestion control methods for end-systems.
>>     There are not many venues where these practitioners interact on a
>>     deep level, yet their end-products may interact significantly,
>>     since they are both part of the end-to-end path. There are other
>>     community members that have a keen interest in, or impact on
>>     end-to-end performance, e.g., network operators and middle-box
>>     designers.
>> 
>>  *  We propose to survey the stakeholder communities, to see if there
>>     is interest in convening a workshop targeted at identifying and
>>     understanding interactions between in-network queuing strategies,
>>     and end-system congestion control (CC) behavior. It may be that
>>     this topic has been probed, and/or that there is not sufficient
>>     interest in converging these groups. But it is also quite possible
>>     that the two communities have not had sufficient interaction in the
>>     past, and the larger TCP community may benefit from a broader
>>     understanding of the interplay between in-network queuing
>>     strategies and end-system congestion control algorithms.
>> 
>>  *  Relevant questions whose probing may benefit both communities
>>     include: "What are commonly deployed in-router queue management
>>     strategies, and what is the innovation rate in that space?"; "What
>>     is the spectrum of congestion control strategies (e.g.,
>>     sender-side-only, need-help-from-router, loss-based, delay-based,
>>     combinations)?"; "How much do we understand about interactions or
>>     dependencies between queuing and CC?"; "How do choices made by
>>     either community impact incremental deployment possibilities?";
>>     "What are tradeoffs in incorporating some level of responsiveness
>>     to low-rate probes in routers (vs. per-packet processing)?"; "Are
>>     there characteristics of some CC algorithms that make them robust
>>     to a wide variety of queue management strategies?"
>> 
>>  *  For example, one common mis-fire between (congestion control)
>>     researchers and  (router queue) implementers occurs when algorithm
>>     developers design innovative methods that require "a little
>>     per-packet help from the router." When this conversation is brought
>>     to router designers, the pushback is sometimes of the form, "Well,
>>     that would have to go into hardware; we could do it, but this
>>     better be *the* winning algorithm for the Internet, because we can
>>     only do it once." Or, "forget it."  Conversely, if router designers
>>     saw value in incorporating low-level tools that provided
>>     flexibility in some minimal number of high-speed per-packet
>>     operations, interactions between queuing and congestion control
>>     might flourish.
>> 
>>  *  Possible sponsors for such a workshop include: NSF, DOE, IETF,
>>     ACM-Sigcomm, and Internet2-Joint_Techs.
>> 
>>  *  TBD- committee, paper/participant invitation/selection,
>>     location, duration
>> 
>> <end>
>> 
>> 
>> Best regards,
>> Larry
>> --
>>