Transport protocols and bulk file transfer

[stanislav shalunov <>]

                       Bulk Transport Tool Call
                       Friday, December 3, 2004

Attendees:

        Larry Dunn
        Stanislav Shalunov
        Eric Boyd
        Matt Zekauskas
        Lisong Xu
        Martin Swany
        Yunhong Gu
        Injong Rhee
        Xinwei Hong
        Steven Senger
        Susan Evett (scribe)

Call started at 12:02PM US/Eastern.

Agenda
Changes? Additions? NONE
Larry's comments:  review items
Steve's ``API questions'' email: fuller review deferred to next call
Items for next call  several suggested

Larry's comments:
https://mail.internet2.edu/wws/arc/transport/2004-12/msg00001.html
Most are editorial; sent late enough that folks may not have been able
to review them.  Stanislav: with respect to the first comment, you
seem to be of the opinion that ECN standard changes.  Larry: only
point was that it is not ECN's job to change to meet the congestion
control algorithm (CCA).  Stanislav: do you envision any other uses
for ECN in the future?  Larry: my complaint is that it doesn't change
the nature of the CCA; ECN is 'inferior' because it doesn't do that
but I disagree.  It is flexible.  Have ECN back off by a factor of 10
or whatever to allow the CCA to be more flexible in response.
Stanislav: I didn't intend to suggest that; ECN is not designed to
change the CCA, but it does require that ECN notifications be treated
as losses.  I can't think of a way to interpret the spec where ECN was
not loss-based. Larry: it isn't loss-based if no loss took place
sounds like this is a wording thing. Stanislav: agreed, need to
reword.  (See Action Item 1 at end of notes.)

Stanislav: reference for the "current thinking of using instantaneous"
queue depth vs. current method (average queuing).  Larry: the RED
community have been struggling with this for several years.
Stanislav: I've heard the preferences for instantaneous on several
fronts but not sure if I have a reference for it stated in
lectures/seminars etc.  Can someone on the call dig up such a
reference to a control theory paper that discusses this (I can provide
several names of speakers)?  Injong: more information the merrier how
do you construct the CCA do you react to the instantaneous reports or
not?  You can if you want to; more information isn't bad depends on
the CCA you're relying upon.

Injong: new transport protocol is reacting to every behavior and it is
being widely adopted.  Larry: I think we should clarify to say giving
more information is good so you can do your own filtering but
indicating that this is a required/necessary/best using instantaneous
could cause oscillation. (See Action Item 2 at end of notes.)

Injong: new paper (Bong and Park?)  saying that if you don't have
nearly all the routers providing this support, XCP doesn't work very
well.  (See Action Item 3 at end of notes.)

Stanislav: you support another system that doesn't require XCP; later
you need to use XCP; you'd need to be sure all the routers along a
path support XCP; can't send message that says "if you're a bottleneck
router, please decrement TTL" doesn't work.  Larry: have one border
router implement XCP interior routers don't need to use it but you'd
get more limited info.

Matt: Aaron Falk has a draft that talks about the open question about
mixing up systems on routers. (See Action Item 4 at end of notes.)

Stanislav: ``need to double user-observable delay'' you could use many
other solutions (reduce buffer sizes, deploy QoS, not use the Internet
for voice, etc.)  denying the problem of needing small queues.  Larry:
to pull in VoIP and its needs for a bulk transport seems a waste.
Stanislav: I'm just using VoIP as an example because I understand the
requirements for delay.  It is harder to assess the important
thresholds for games and other interactive applications.  The wording
needs to be changed to indicate this is just an example (not a
requirement).  (See Action Item 5 at end of notes.)

Stanislav: ``reference for user space'' --- How about ``iperf -b1g''
for a reference?  Don't know if we could find a citable reference for
this.  Larry: I would be comfortable with anecdotal reference.
Stanislav: we need to be picky on our comments if something
bugs/bothers you or you find it hard to understand it initially, let's
reword it.

                       API Document Discussion

Steve sent around his document this morning.  Stanislav noted that it
had gone out close to one hour before the meeting and that he'd not
been able to read it yet.  He suggested that the group delays
discussion until people have a chance to read it either a) next call
or b) via the mailing list.  Steve: My uses of this is very different
than other people's I wanted to know whether there is interest in
supporting the overlap I/O option, access to single packets, etc.  We
talked about what to do about minimizing buffer copying suggestions
would be useful.  I'd like something that respects message boundaries.
Also, given the temporary spike in packet loss I sometimes experience,
I'd like to see a socket option to change the policy about resending
packets.  If folks are OK with that, I'll start working on the API
document.

Larry asked for Steve's background / use of this; Steve gave him
background on his experience and needs.  Larry was wondering about
whether there was any consideration of ``loosely-reliable'' (like
SCTP); Stanislav: SCTP is a new transport protocol with many options
(multiple associations, multi-homing, DCCP-like ``UDP with congestion
control'').  It has a lot of features that we're not discussing here.
Larry: I was interested that some of the issues that Steve is
concerned about we should take a look at it.  Steve: I'll take a look
at it and, if it seems reasonable, I'll work it into the API.  If
there are methods that are reusable, I'll try to work off them.  (See
Action Items 6 & 7 at end of notes.)

Stanislav spoke to Guy in re what he was doing.  He feels it is
nothing we could apply for unless we form a new SC center.  He said we
might have better than average chances with NeTS but wasn't promising
on that either.  Martin: I haven't had a chance to talk with my
contact due on Monday.  Stanislav: could you discuss this at our next
call?  We have a deadline fast approaching.  (See Action Item 8 at end
of notes.)

Group deferred.  Stanislav: some folks have sent comments on the
design space document encourage folks to ensure that all work is
included.  Need to finish it soon.

Other funding opportunities?  None suggested.

Susan reviewed all the action items that were collected.  Larry made a
request for an agenda item for a future call what he can't figure out
is, after the design space document is complete, how will the group
interact?  Will we be using our own protocols?  Competing over them?
Etc.?  Stanislav asked for comments.  Injong: thinks we need several
more sessions to iron out goals and approaches for it different folks
have different approaches in mind hard for all of us to stick to one
approach.  Need to form sub groups to develop protocols to compare
them.  Major discussions and negotiations in the future but not sure
how we do that.  Larry: sounds sensible but I wanted to clarify that
this could be difficult.  Stanislav: the goal is a tool that works for
normal users for their needs that use whatever OS/machines they have;
we want it to use the advances in Transport protocols.  Injong: yes,
that's the overall approach I'm wondering what we'll do in practical
effort.  Stanislav: a lot of that material is in the requirements
document probably need to discuss these again.  (See Action Item 9 at
end of notes.)

Larry: timely goal (get it done) vs. the wide flexibility that would
occur if several approaches were developed concurrently.

ACTION ITEMS:
1.      Action Item: Stanislav to reword the ECN entry
2.      Action Item: Stanislav to query his contact who was the
        critic of the RAD approach to see if he can get a reference.
3.      Action Item: Injong to send link to paper to group.
4.      Action Item: Matt to send link or relevant paragraphs to the list.
5.      Action Item: Stanislav will make a wording change to indicate
        that VoIP is just an example of the interactive applications that are
        affected by delay.
6.      Action Item: Steve to review the existing spec for SCTP to see
        if any portions are reusable.
7.      Action Item: Group to review Steve's submission and be
        prepared to discuss next call.
8.      Action Item: Martin to report back on NeTS.
9.      Action Item: Stanislav will pull out the piece of the proposal
        with the requirements and put it into the Design Space document
        (requirements, dimensions, conclusions).

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

Call ended at 12:55PM US/Eastern.