Transport protocols and bulk file transfer

[Scott Brim <>]

Regarding the mail below, my slide on this for the CTO update session
currently says:

* With the Transport Working Group and Net+

* New ways to get better performance out of the network, end-to-end

* Intermediary-based performance enhancement

  Phoebus and XSP

  Other possibilities such as ALTO

  Remote access, cloudbursting, latency

* Endpoint-based performance enhancement

  TCP evolution, SCTP, multipath transport, new in-band signaling

  Monitoring to improve quality: perfSONAR development, Periscope,
  performance monitoring and management for Phoebus and OpenFlow


>> Here are some top-of-mind issues.  For my slide I'm mostly interested in
>> the middle level of indentation, not the specific examples.
>>
>> Enhancing performance:
>>
>>  We can't have helper nodes like Phoebus everywhere, particularly
>>  when crossing multiple networks.  Should we be considering more
>>  end-to-end approaches?  Examples:
>>
>>    - TCP tuning (Hamilton Institute, Multipath TCP?)
>>    - Per-flow in-band signaling
>>    - Per-flow in-band signaling with help, e.g. Larry Roberts's
>>      flow-state-aware forwarding.
>>    - SCTP (in endpoints, independent or with GridFTP, but also at the
>>      net edge in Phoebus or Cisco NCE?
>>    - Enhancements to GridFTP in general?
>>    - Other services besides moving files.
>>
>>    ... but the main question is whether endpoint-based approaches
>>    belong on our agenda, or have they been explored and determined not
>>    to be as productive in any situation.
>>
>>  Information exchange between functional elements so that they can use
>>  the network better.  Examples:
>>
>>    - Phoebus does this by exchanging information with peers, right?
>>    - ALTO and ALTO extensions
>>    - Leaking routing information from internal & external routing
>>    - SDN for some value of D
>>
>> Performance monitoring:
>>
>>  PerfSonar futures?
>>  Other?
>>
>> Deployment:
>>
>>  This group has an operational aspect too, not just making
>>  recommendations.  Once we have research we like, we need to encourage
>>  getting it hardened and production-ready.
>>
>>    - Phoebus is an obvious one.  Anything else?
>>
>> Thanks ... Scott
> 
> 
> On Mar 23, 2012, at 4:44 PM, Jason Zurawski wrote:
> 
>> All;
>>
>> On 3/23/12 2:14 PM, thus spake Scott Brim:
>>> Here are some top-of-mind issues.  For my slide I'm mostly interested in
>>> the middle level of indentation, not the specific examples.
>>>
>>> Enhancing performance:
>>>
>>>   We can't have helper nodes like Phoebus everywhere, particularly
>>>   when crossing multiple networks.  Should we be considering more
>>>   end-to-end approaches?  Examples:
>>>
>>>     - TCP tuning (Hamilton Institute, Multipath TCP?)
>>
>> Martin may chime in more, but one of the selling points of Phoebus was
>> to avoid the dark art of TCP tuning.  Its 'easier' on windows/OX, but
>> near impossible on the latest version of windows.
>>
>> In any event, this is recommendation #1 for enabling data intensive
>> science.
>>
>>>     - Per-flow in-band signaling
>>>     - Per-flow in-band signaling with help, e.g. Larry Roberts's
>>>       flow-state-aware forwarding.
>>>     - SCTP (in endpoints, independent or with GridFTP, but also at the
>>>       net edge in Phoebus or Cisco NCE?
>>>     - Enhancements to GridFTP in general?
>>>     - Other services besides moving files.
>>>
>>>     ... but the main question is whether endpoint-based approaches
>>>     belong on our agenda, or have they been explored and determined not
>>>     to be as productive in any situation.
>>>
>>>   Information exchange between functional elements so that they can use
>>>   the network better.  Examples:
>>>
>>>     - Phoebus does this by exchanging information with peers, right?
>>>     - ALTO and ALTO extensions
>>>     - Leaking routing information from internal&  external routing
>>>     - SDN for some value of D
>>>
>>> Performance monitoring:
>>>
>>>   PerfSonar futures?
>>
>> Periscope - I would welcome the IU/UDel folks to explain the crucial
>> improvements.
>>
>>>   Other?
>>
>> - What can a SDN tell you about its performance, and what do we want
>> to know about an SDN's performance.
>>
>>> Deployment:
>>>
>>>   This group has an operational aspect too, not just making
>>>   recommendations.  Once we have research we like, we need to encourage
>>>   getting it hardened and production-ready.
>>>
>>>     - Phoebus is an obvious one.  Anything else?
>>
>> - Monitoring to go w/ Phoebus
>> - The elimination of tools like SCP (or at a bare minimum, getting
>> openssh to accept the patch from PSC...).
>>
>> Thats about all I can muster late on a Friday.
>>
>> Thanks;
>> -jason
>