Columbia Kermit/kermit.zip/protocol/nagle-streaming.txt

Text File | 2020-01-01 | 6KB | 123 lines

12-Nov-97 20:54:18-GMT,5578;000000000001
Return-Path: <jaltman>
Received: (from jaltman@localhost)
    by watsun.cc.columbia.edu (8.8.5/8.8.5) id PAA11570;
    Wed, 12 Nov 1997 15:54:17 -0500 (EST)
Date: Wed, 12 Nov 97 15:54:17 EST
From: Jeffrey Altman <[e-mail]>
Reply-To: [e-mail]
To: Frank da Cruz <[e-mail]>
Subject: Re: I couldn't help it
In-Reply-To: Your message of Wed, 12 Nov 1997 15:28:48 -0500 (EST)
Cc: [e-mail]
Message-ID: <[e-mail]>

> Here's a rough draft to start things off.  Don't worry about the negotation,
> just try the stuff at the end....
>
> STREAMING KERMIT PROTOCOL FOR RELIABLE CONNECTIONS
>
> Why is FTP faster than Kermit on a TCP/IP connection?  Even when Kermit is
> tuned for top speed, FTP can still be significantly faster.  Much of this is
> caused by the added overhead from going through a Telnet server on the far
> end.  But even when the remote Kermit is set up to listen on its own TCP
> socket to bypass the Telnet server, FTP is still faster.  Why?  Because when
> transferring data, it does not use, and therefore does not wait for,
> acknowledgements.  It relies on TCP and IP to provide a reliable data stream,
> and it uses a second channel for control signaling.
>
But why, in a sliding window protocol like Kermit, should ACKs slow things
down at all?
Because of conflicts between the Nagle and Delayed Acknowledgement
Algorithms designed to reduce inefficient network traffic.  The Nagle
algorithm restricts the number of unfilled TCP data segments to one
per connection by refusing to send additional data until an
acknowledgement is received.  The Delayed Acknowledgement algorithm
delays the sending of an ACK hoping that there will be some real data
to piggy back it on.

Kermit ACKs are so short that they always trigger the Nagle algorithm.
That in itself is not a problem.  However, the sending of a Kermit ACK
resets the Delay Ack timer.  Many implementations of TCP/IP, such as
Microsoft Winsock 1.x and 2.0 and SunOS, use a hardwired 200msec timer
regardless of the Round Trip Time of the connection.  While this would
not create a significant issue for connections whose RTT was greater
than 200 msecs it proves to be a major waste of bandwidth when the RTT
is on the order of 1ms or smaller.

(I still need to clean this up; show network timings, ...)

> One way around this problem is to not send or expect ACKs during the data
> portion of a file transfer when we know the underlying transport is reliable.
>
> HOW DO WE KNOW WHEN WE HAVE A RELIABLE TRANSPORT?
>
> The Kermit program that makes the connection knows what the underlying
> transport is, and therefore whether it is reliable.  When it is a TCP
> connection, in most cases it can be considered reliable, since error detection
> and correction are done by TCP, IP, and the layers below.  Similarly for X.25
> and other reliable end-to-end protocols.  A serial connection, on the other
> hand, should never be considered reliable, even when error-correcting modems
> are involved, for all the well-known reasons (lack of effective flow control,
> interrupt conflicts, loose wires, etc).
>
> The remote Kermit can not usually tell what kind of connection it has, and
> so some means is required to tell it that it has a reliable one.
>
> This can be done by command, or the information can be conveyed from the
> local Kermit via protocol.
>
> In some cases, a reliable transport is not truly reliable; for example, a TCP
> connection to VMS can still lose characters if the remote session has certain
> parameters set, such as TERMINAL /NOTTSYNC /NOHOSTSYNC.  So commands are
> necessary in all cases to let the user have the final say about whether a
> connection is reliable.

Another example is Telnet to a terminal server for access to a
outgoing modem.

> SUGGESTED PROTOCOL
>
> When a Kermit program believes it has a reliable connection, it can inform
> the other Kermit program via the WHATAMI mechanism, Bit 3, which is presently
> reserved.  If either Kermit sets this bit, they both can assume they have
> a reliable connection.
>
> At this point they also need to let each other know they are capable of
> ACKless transfers, and this will require another capability bit, to be chosen
> later.
>
> Once they have agreed to use ACKless protocol:
>
>  . The sender does not wait for ACKs to D packets, but keeps sending the
>    file without pause until the end, at which point it sends a Z packet in
>    the normal manner.
>
>  . The receiver does not send ACKs for D packets, but simply writes incoming
>    data to disk.  The underlying transport handles pacing and flow control
>    automatically.  When the Z packet arrives, the file is closed and the
>    Z packet is acknowledged.
>
> Implementation in C-Kermit:
>
>  . Sender: the input() routine in ckcfn2.c examines the sndtyp variable
>    and if it is "D", it marks the packet as ACK'd (see the section at the
>    beginning of the "if (nakstate) { } else part) and then returns immediately
>    a "Y".
>
>  . Receiver: in <rdata>D state, it simply skips sending the ACK.
>    Well, it calls a special version of ack() that does everything that
>    the real one does EXCEPT send it.
>
> - Frank
>

- Jeff

    Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
                 The Kermit Project * Columbia University
       612 West 115th St #716 * New York, NY * 10025 * [phone]
    http://www.columbia.edu/kermit/k95.html * [e-mail]