[e2e] Is a non-TCP solution dead?

[Jonathan Stone]

Alex,

I see some fairly distinct issues here. For reasons I don't understand,
you seem determined to conflate them. Let's not conflate.

The first point I'd like to address is your claim that TCP's
ACK-every-other-packet was a contributor to your, war-story
about poor file-transfer performance.

I report, again, the *fact* that a TCP will ACK every other segment
need not, in itself, be a throughput bottleneck.  In a modern TCP
(or any TCP which has caught up with RFCs more than 10 years old!),
window sizes *do* grow sufficiently large that a TCP sender can transmit a
burst of over 40 full-size Ethernet segments, without receiving a
single ACK -- in fact, all 40 segments receive at the receiver before
the ``communication network'' (rfc793) even informs the receiving TCP
of the first packet in the burst.

That is *not* a ``driver'' issue. That is an observed fact about TCP
window sizes, and the consequent ability of TCP to send data without
necessarily receiving prompt ACK segments.  In light of that observed
fact, your claim about one-ACK-every-two segments is (again) specious.


Now another issue.  You did supply slights more detail about the
alleged bad file-transfer performance being due to TCP:

  > [...] no, I'm not referring to what you term RPC/CIFS [...]

  >I'm referrring to an ordinary file transfer, say from an NT server to
  >a workstation, where TCP/IP is the installed stack.  This has been a
  >common config ever since Microsoft began shipping TCP/IP.

Point of information: network file accesses between Microsoft NT file
servers using SMB over TCP/IP, actually employ *CIFS* over SMB over
TCP.  [Leaving aside  remote possibilities, like DFS over MS's DCE RPC].

Were you using some other file transfer protocol atop SMB-over-TCP?


>By the way, since we're about 2 miles from one another, I'll be happy to show
>you any data you'd like to see.

Post a URL to a packet trace, please. (libpcap preferred, so we can
feed it into Shawn Osterman's tcptrace; but not required).  If TCP is
truly as bad as you say, there's lots of us hungry to publish papers
analyzing the problems and proposing ways to fix them.