Transport protocols and bulk file transfer

["Lawrence D. Dunn" <>]

Colleagues,
  Here are some notes on sections "4" through the end...

  (BTW- I'm OK if we let folks read it and comment via
  email for a week, rather than taking time on the
  call-the-day-after-i-send it.  Your call, Stas...)

4.1 point "3"
  "failing closed" is not a universally understood term
  (and a dynamite detonator that "fails closed" may be
  more robust to its eventual purpose, but is not safe...)

4.2 timestamps
  I'm ignorant as to whether the inclusion of timestamps
  could impact the CPU/efficiency of the process
  enough to alter the achievable rate.
  Voices of experience?

4.6 "Selective Acknowledgements"
   Parts of section 4 read as tutorial;
  in 4.6, we use(lead-off) with the term "Selective Acknowledgements",
  but never mention SACK in the body.  May as well include
  a reference to SACK, particularly given the tutorial-feel
  of the rest of the paragraph.
  I'm not quite sure what the last sentence means: "...mechanism.. same
  as for regular transmission"

4. general
  The section is called "Protocol format and framing"
  but a couple of the paragraphs delve into mechanism;
  maybe "4" needs some small re-titling,
  like "Protocol features and framing" or similar
  (I also think the difference between "format"
  and "framing" may be too subtle for many readers?).

4.7. Request compression ratio
  I'm not sure it's quite true/relevant that
  the*packet* ratio needs to be <<1 (<1?)
  to "use the network resources efficiently".
  Also, "considerably smaller" is vague.
  I agree it's a worthy goal to be able to control
  the ratio, but it might suffice that the byte-ratio
  is <<1.  Also, if the reverse-path is uncongested,
   it's not cleat that reverse-direction efficiency is even
  important (and if that's an information channel
  w.r.t. controlling send-rate, then we may want to reduce
  pkt- or byte- efficiency to gain information rate).
  So I'm not arguing against a control method, just think
  that the logic of "why" and the metrics (pkt-based)
  might warrant further thought.

5. Window- vs. rate- based
  Need to be careful about the term
 "kernel TCP patch" as I think sometimes
  folks consider wholesale replacement
  of the OS-provided algorithm as a "kernel patch".
  I suppose you mean "patch" as in "minor editing
  to the OS-provided TCP-algo source".
  Of course, some kernels now come with several
  algorithms included.  So I think this paragraph
  is too strong.  How do we know which algo. is
  being "patched"? embedded Reno? Vegas? embedded FAST?
  Then again, I think I've been in conversations where someone
  refers to FAST as a "kernel TCP patch", which of
  course takes us from window- to delay-based via a "patch".
 So depending on the reader, the "hardly relevant" is
  a little strong, and open to confusion.
  I'm also confused by telling the reader that it is
  "hardly relevant", and then "has not been studied"
  in the same paragraph (in which case, how do we
  know it is hardly relevant or not?)

5. "...can have fewer bursts or they can be smaller" ->
  "...can have fewer bursts, or the bursts can be smaller".
  (ambiguous referent)

6. "compatibility vs. friendliness..."
  "...becoming obsessed with necessarily being TCP-compatible..."
  is inflammatory and pejorative.
  Perhaps "requiring strict adherence to TCP-compatibility..."?
  Also- it's not clear that requiring TCP-compatibility leads to
  "same performance as conventional TCP".
  (Lossless environment being obvious counterexample).
  Perhaps it would help the reader to characterize
  HS-TCP, FAST, BIC, etc as to whether you view them,
  with the proposed definition of terms, as "compatible"
  or "friendly".  Under the definition and conclusion that
  "compatible --> *same* performance", is *any*
  algo,. compatible with Reno except Reno?
  I can't tell if this section is a complaint about 2914's relevance
  or choice of wording, or lack of common usage of terminology,
  or something else.

7. state location
  No real comments. Though it might be nice to provide a
  word or two on how receiver misbehaves to get unfair-share,
  instead of making the reader chase the reference.

8. UI/API
  UI- thought not exactly a "UI", might it be sensible to provide
  hooks/code for web100 to provide some display?
  I'm not sure how (non-)trivial it is, but being able to
  view/tweak state through gutil, and compare w/ other
  protocols through that vehicle, might be worthwhile.

(appendix) "A"
  Should probably prepend the word "Appendix"?
  I've provided some comments/questions on this section in
  previous mail; I have a few more, but am happy to defer them.
  OK, one example: I'm unconvinced by the assertions about
  date rate and convergence time; they seem predicated on
  linear-bit-density, integer representation?
  But  the controller, knowing it's bit-rate transfer limitations,
  could choose an encoding that traded off precision for range,
  to speed (approximate)convergence.
  Mantissa/exponent format is simple example.
  It's not clear that "convergence" to a specific value
  is a requirement of this application (<=upper_bound
  is probably more useful, closer being better, perhaps...)
  I'm not saying it's the "right" way to do it, just that
  it makes me uncertain of the validity/applicability of the (overly?)tight
  set of assumptions that lead to the nice math.

References
(seems OK, though I didn't read too closely)