Transport protocols and bulk file transfer

["Lawrence D. Dunn" <>]

Folks,
  Here are some quick comments(Intro + sec. 1..3 only, ran out of time...):


Intro:
" This limits the space given
to discussion of some options that cannot be imple-
mented in the near future."
<confusing sentence...>

1.2 ECN
Text criticizes that ECN doesn't include a change in the
congestion control protocol.
This is co-mingling two potentially separable issues.
The feedback from ECN was developed before the plethora
of alternate stacks.  There is nothing to prevent those stacks
from using ECN as a trigger or piece of information, so this
criticism/conclusion:

"Unfortunately, ECN is almost exclusively a mecha-
nism to replace some (possibly almost all) packet
losses with congestion notifications, without a change
in the nature of the congestion control algorithm"

feels unwarranted and overstated.

1.2. ECN
"prohibits... instantaneous...current thinking seems to indicate..."

reference/basis(for "current thinking", please?- lest we sound
pretentious like "everybody should know this".)

I don't think we want a huge discussion of control theory,
feedback loop timing, stability, etc.; OTOH, that does
underpins much of what we're working on...

1.4. XCP
There is a claim that all routers on path must use XCP.
What's the evidence for that?  Like QoS, it's probably
critical (and is in Dina's work somewhere)
for limiting/bottleneck routers to have XCP.
I'm not saying that makes XCP much more deployable, just that
the "all routers" claim isn't quite accurate.

2.1 Loss-based CC

"...to which the practicality consid-
erations of section 1 apply)"

There is no section labeled "practicality considerations";
if you have  a 2-word conclusion/caution, state it explicitly here.
Otherwise it contributes to "gee, what was that- do I have to go back and
re-read it?" feeling.

2.1
"user observable delay... need to double"
This whole section is a bit shaky, as it seems to
assume a single-queue model.  But then tries to
tie-in problems with VOIP.
This denies the possibility(reality?) of using multiple
queues.  I think you'll find several providers that do treat
voice differently, at least at high-probability-of-congestion points.
That doesn't obsolete the point being made,
but using such a "of course VOIP delays would double and
that can't be allowed"
assertion will make folks think we're not trying to reflect/assess reality.

2.1 response function...
"it is unlikely that the response function
of sending rate to loss probability p can be made
to grow faster than 1/p as p -> 0."

Stated without appropriate support(you may want to forward reference
the proof earlier in the section).  I'll re-read the proof, but I'm not
sure it helps- in that it assumes one (of several possible)
response function forms, then does the math.
This is asking for trivial (also without support)
mathematical refutation.
Like "Well, my response function is designed to -> infinity
as p -> 0".  So it's indeterminate.
I guess I'm suspecting that  the "proof" is starting from an
 overconstrained solution assumption; issues that come to mind,
  for example: is p really constant? If not, does Shannon's formula apply?
  If the information transfer is characterized by multiple flavors
  of feedback (or non-linear response, or regime-detection thresholds,
  etc., does the proof apply?  I think we see some of this in current
  alternate stacks.  So if the proof is applicable to too-narrow a
  solution space, is it useful?  I'm not trying to ditch/refute it yet,
  just airing some of my uncertainties...)

Maybe just cite current algorithms and point out what they do?
  (which is sort-of what the para. just before sec. 2.2. does, I think)

2.1 closing para
"Thus not only..."
Sentence is awkward.

2.4 1st sentence
  run-on, awkward- break it up.

3.2 "User space ... performance ... good as kernel..."
  (any reference?)

< OK, I'm out of time- I'll try to get comments for
  sections 4-8 out before next week's call...>

Larry
--