Transport protocols and bulk file transfer

[Scott Brim <>]

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
> --