Some time ago (several years, probably) I had some questions regarding our
TCP/IP vendor and the fact that they would seem to always wait for an ACK
before sending the next packet. I think it was pretty much agreed upon here
that this was fairly non-standard (though not necessarily "forbidden" by any
relevant RFC), and would also result in longer transmission times. The
vendor argued that it is done in the name of 'data integrity'. Others
argued, of course, that even though the receiving TCP acknowledged a packet
that that does not necessarily mean that the packet had been forwarded to
the receiving application, or even if it was if the receiving application
had handled it successfully. I could never seem to convince the vendor,
though.

Anyway, that vendor (CSI International; http://www.e-vse.com/) just released
a new version of their product, TCP/IP for VSE (version 1.5E). They have an
agreement with IBM to "brand" their product as part of the IBM z/VSE
operating system. The following is an interesting comment from IBM's
website, where CSI had described features of this new version.

--------------------------------------------------------------------------
http://www-1.ibm.com/support/docview...id=isg1II14121

SET SENDFAST ON/OFF Default: OFF
"Data integrity" is a mainframe concept that, unfortunately, was
not ported into the Personal Conputer and Internet models.
To ensure that data is not lost on the network, TCP/IP for VSE
applications do not presume data-packet delivery unless and
until an ACK is received for the packet from the remote host.
Although this does not mean that the remote application has
received and processed the data, at least the uncertainty of the
network connection is not an issue.
Although this can --and does-- reduce the "average" transmission
speed for each connection, it does increase data integrity.
Because the File Transfer Protocol includes an acknowledgement
by the application that the data file has been successfully
received, and successful CLOSE processing includes an
acknowledgement by the remote stack that every transmitted byte
has been received and (in theory) given to the FTP application,
it is possible to speed-up the data transmission process without
sacrificing data integrity.
If you specify "SET SENDFAST ON", FTPBATCH will queue output
data continuously, without waiting for any acknowledgement of
receipt by the remote host. The program will monitor the total
yet-to-be-sent datagrams queued in the TCP/IP stack partition
and will pause only when there is a sufficient backlog of data
to ensure complete use of the network adapter.
Only during CLOSE processing will a cummulative acknowledgement
be required for the entire transmission.
As always, FTPBATCH will also require that the remote FTP
application send a standard open-text acknowlegement over the
separate "control" connection.
The "SENDFAST" option is "OFF" by default. This is because the
concept is a significant departure from previous operation.
--------------------------------------------------------------------------

Am I imagining things or are they just being totally obstinate with regard
to this issue? They grudgingly acknowledge that "their way" is slower, but
they insist it is still more reliable. Is it really?

Anyway, I'm just glad to have "in writing" comments from them on this
issue.

Any comments welcome, though probably useless. :-)

Frank


---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA

"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> writes:
> Some time ago (several years, probably) I had some questions regarding our
> TCP/IP vendor and the fact that they would seem to always wait for an ACK
> before sending the next packet. I think it was pretty much agreed upon here
> that this was fairly non-standard (though not necessarily "forbidden" by any
> relevant RFC), and would also result in longer transmission times. The
> vendor argued that it is done in the name of 'data integrity'. Others
> argued, of course, that even though the receiving TCP acknowledged a packet
> that that does not necessarily mean that the packet had been forwarded to
> the receiving application, or even if it was if the receiving application
> had handled it successfully. I could never seem to convince the vendor,
> though.

remember that SNA had been pretty much half-duplex protocol ... which
met continually waiting for the link to turn around. there was even a
document about attempts to implement lu6.2 on top of a tcp/ip layer
and the horrible problems trying to get half-duplex lu6.2 to deal with
asyncronous, full-duplex tcp/ip transmission layer.

the original vm/mvs tcp/ip product was implememted in vs/pascal and
got something like 44kbytes/sec aggregate thruput and consumed a 3090
processor doing it. i had added rfc 1044 support to the product .. and
in testing at cray research between a cray and a 4341-clone ... was
getting 1mbyte/sec aggregate thruput using only a portion of the
(4341-clone) processor.
http://www.garlic.com/~lynn/subnetwork.html#1044

one of the protocols used was NAK and selective-resend for missing
packets and/or packets in error.

for high-speed local area network .. it might not be much of an
issue ... but one of the things we did as part of the hsdt project
http://www.garlic.com/~lynn/subnetwork.html#hsdt

was a high-speed backbone for the internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet

that included some number of full-duplex T1 satellite links
.... full-duplex asyncronous operation could easily have twenty 4k-byte
packets outstanding simultaneously in both directions on a link. with
approx. 22k miles to orbit ... or 4*22k miles for complete round-trip
.... comes out to approx. half-second round-trip latency. half-duplex
syncronous operation would have been two packets/sec thruput ...
while the rate-based pacing and selective resend that was implemented
could drive a full duplex T1 at nearly media speed (about
300kbytes/sec or 75 4k-byte packets/sec).

for additional data integrity ... the outboard satellite link also
included 15/16 reed-solomon forward error correcting.

a few recent posts discussing various aspects of hsdt effort
http://www.garlic.com/~lynn/2006e.html#36 The Pankian Metaphor
http://www.garlic.com/~lynn/2006l.html#4 Google Architecture
http://www.garlic.com/~lynn/2006s.html#42 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2006s.html#50 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2006t.html#6 Ranking of non-IBM mainframe builders?

Anne & Lynn Wheeler <lynn@garlic.com> writes:
> was a high-speed backbone for the internal network
> http://www.garlic.com/~lynn/subnetwork.html#internalnet

re:
http://www.garlic.com/~lynn/2006u.html#44 waiting for acknowledgements

actually the selective resend didn't do a lot of good early on. all
the links that left corporate facilities (including satellite links)
had to be encrypted (at one point somebody claimed that the internal
network had over half of all the link encrypters in the world).

in any case, early on, we had to settle for some (essentially)
off-the-shelf T1 link encrypters ... when things got too garbled the
link encrypters retrenched to initial syncronization mode ... which
could last long enuf (especially on sat. link) that the software would
think the link had dropped and would automatically recycle
it. fortunately the 15/16 reed-solomon forward error correcting ed
minimize the number of times that happened.

later i was involved in designing an inexpensive crypto board that
minimized the crypto resyncronization problem (that was also targeted
at being able to handle a couple megabytes/sec ... bytes not bits).

You raise a very good question:

When is an acknowledgement sent back for TCP ?

Some possible answers:

1. The stack receives and queues the packet. The stack acknowledges the
packet even though the user has not yet "picked up" the packet.

2. The stack receives and queues the packet. The stack does not acknowledge
the packet until the user has "picked up" the packet.

Answer 2 is unlikely because the sender would then keep retransmitting the
data until the user finally picks up the packet and the stack sends back an
acknowledgement.

TCP was designed with network efficiency in mind.

I would be surprised if in reality TCP uses answer 2.

In reality TCP probably uses answer 1.

So it is possible that a packet was acknowledged but it was never picked up
by the user and the system crashed.

The sender is correct in assuming the packet arrived at the receiver.

This does not mean the packet was processed.

More communication will need to take place to make sure everything was
processed etc.

This is what the FTP thing is for.

Normally TCP simply stops transmitting new segments if it detected the
buffer at the receiver was full.

Anyway it is safer to wait for an acknowledgement because for high speed
networks the TCP sequence number can wrap back real fast and cause problems.

I advice you to trust IBM for now otherwise they would have been out of
bussiness a long time ago

Bye,
Skybuck.

"Skybuck Flying" <spam@hotmail.com> writes:
> You raise a very good question:
>
> When is an acknowledgement sent back for TCP ?
>
> Some possible answers:
>
> 1. The stack receives and queues the packet. The stack acknowledges the
> packet even though the user has not yet "picked up" the packet.
>
> 2. The stack receives and queues the packet. The stack does not acknowledge
> the packet until the user has "picked up" the packet.
>
> Answer 2 is unlikely because the sender would then keep retransmitting the
> data until the user finally picks up the packet and the stack sends back an
> acknowledgement.
>
> TCP was designed with network efficiency in mind.
>
> I would be surprised if in reality TCP uses answer 2.
>
> In reality TCP probably uses answer 1.

re:
http://www.garlic.com/~lynn/2006u.html#44 waiting for acknowledgements
http://www.garlic.com/~lynn/2006u.html#45 waiting for acknowledgements

note that the possibility would still exist that an application could
fail to pickup a packet even in a half-duplex synchronous scenario ...

if you are looking to deal with that fault scenario ... the
application would need some higher level logic regardless of which
scenario that tcp/ip used (synchronous 1 block at a time, or some
N-blocks outstanding asynchronous). if tcp/ip acks a packet before the
application signals that it has completely processed the packet
.... there is still all sorts of opportunities for things to go wrong
.... whether it is a single packet outstanding or 100 packets
outstanding.

In article <4s14epFt9plqU1@mid.individual.net>,
"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote:

> Am I imagining things or are they just being totally obstinate with regard
> to this issue? They grudgingly acknowledge that "their way" is slower, but
> they insist it is still more reliable. Is it really?

If their version of the send() call blocks until the acknowledgement is
received, then applications have a guarantee that no network problems
have interfered with the data transmission. This is a little better
than the standard mechanism -- it's pretty rare for an application to
fail to read a packet that has been received and buffered by the stack.
The only case that's likely to cause a problem is if the application
crashes after the stack has acknowledged receipt of the data.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

Barry Margolin <barmar@alum.mit.edu> writes:

> In article <4s14epFt9plqU1@mid.individual.net>,
> "Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote:
>
> > Am I imagining things or are they just being totally obstinate with regard
> > to this issue? They grudgingly acknowledge that "their way" is slower, but
> > they insist it is still more reliable. Is it really?
>
> If their version of the send() call blocks until the acknowledgement is
> received, then applications have a guarantee that no network problems
> have interfered with the data transmission. This is a little better
> than the standard mechanism -- it's pretty rare for an application to
> fail to read a packet that has been received and buffered by the stack.
> The only case that's likely to cause a problem is if the application
> crashes after the stack has acknowledged receipt of the data.

Or if the OS itself crashes or is shut down before the application can
read it, or the application suffers some sort of error (such as "disk
full") and is unable to process the request.

Really, I think the idea of a blocking send here is just plain
foolishness. Removing the network "uncertainty," as they claim, does
not actually do any good in practice and does do demonstrable harm.

It doesn't do any good because getting the bits to the other side is
_not_ the whole job. The whole job is getting the peer application to
process the bits, do something useful with them (perhaps committing
some information to stable storage), and then send back a reply.

Once you have an application-level reply, it no longer matters whether
the original TCP ACK was ever seen. You have a stronger guarantee
from the application behavior itself than you ever could from the
network.

It does demonstrable harm because, as the original poster observes, it
slows things down -- quite dramatically on some networks.

In other words, they're selling snake oil.

--
James Carlson, KISS Network <james.d.carlson@sun.com>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

In article <barmar-5854DE.23094615112006@comcast.dca.giganews.com>,
Barry Margolin <barmar@alum.mit.edu> wrote:
>In article <4s14epFt9plqU1@mid.individual.net>,
> "Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote:
>
>> Am I imagining things or are they just being totally obstinate with regard
>> to this issue? They grudgingly acknowledge that "their way" is slower, but
>> they insist it is still more reliable. Is it really?
>
>If their version of the send() call blocks until the acknowledgement is
>received, then applications have a guarantee that no network problems
>have interfered with the data transmission. This is a little better
>than the standard mechanism -- it's pretty rare for an application to
>fail to read a packet that has been received and buffered by the stack.
>The only case that's likely to cause a problem is if the application
>crashes after the stack has acknowledged receipt of the data.

It sounds like they are catering to very old applications that rely on TCP
(or emulated SNA over TCP) to tell them if any sent message fails to reach
it's destination. In a LAN environment, latency wasn't so bad, but these
days applications get deployed in a WAN environment where latency kills
performance.

The modern way to get their kind of reliability is through transactions.
Typical OS filesystems don't have the kind of transactions that most
databases have. Similarly, applications that live and die by reliability
need transaction support at a layer higher than TCP.

In article <eji8mr$bv1$1@news.xmission.com>,
Howard Johnson <hjohnson@xmission.xmission.com> wrote:

>It sounds like they are catering to very old applications that rely on TCP
>(or emulated SNA over TCP) to tell them if any sent message fails to reach
>it's destination. In a LAN environment, latency wasn't so bad, but these
>days applications get deployed in a WAN environment where latency kills
>performance.

That doesn't sound plausible.
Even 20 years ago such "excessive latency" would have killed performance
on LANs, for values of "killed" that I cared about.
And long before that, there was the notion of a "window" for network
protocols.
And before that there was "double buffering" for tape drives.
And ...

It sounds more likely that an outfit doesn't care to learn what it
is doing. An outfit that gets such obvious things wrong is likely
to do far worse in obscure ways. The right thing to do is to run
away from them as quickly as possible. It would be public spirited
to not point out this error to them so that future prospective
customers can use it as a red flag.

>The modern way to get their kind of reliability is through transactions.
>Typical OS filesystems don't have the kind of transactions that most
>databases have. Similarly, applications that live and die by reliability
>need transaction support at a layer higher than TCP.

Yes, for values of "modern" that cover more than 2 decades.


Vernon Schryver vjs@rhyolite.com

>>>> Barry Margolin<barmar@alum.mit.edu> 11/15/06 9:09 PM >>>
>In article <4s14epFt9plqU1@mid.individual.net>,
> "Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote:
>
>> Am I imagining things or are they just being totally obstinate with
regard
>> to this issue? They grudgingly acknowledge that "their way" is slower,
but
>> they insist it is still more reliable. Is it really?
>
>If their version of the send() call blocks until the acknowledgement is
>received, then applications have a guarantee that no network problems
>have interfered with the data transmission. This is a little better
>than the standard mechanism -- it's pretty rare for an application to
>fail to read a packet that has been received and buffered by the stack.
>The only case that's likely to cause a problem is if the application
>crashes after the stack has acknowledged receipt of the data.

Actually, if I recall correctly (it's been a while and we switched to the
other VSE TCP/IP vendor), the send would not block until the ACK was
received, but if you attempted a second send it would block until the ACK(s)
for the first send was(were) received.

Frank

---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA