design advice

When you try out telnet under Windows, and you start hitting those keys
quite fast, you might notice that Windows actually packs several characters
into a single TCP packet (Nailer algorithm, if I recall correctly).

So since networks already have a delay, implementations add some additional
delays to use the network more efficient (less overhead). The above Nailer
algorithm is also documented in the RFC. Perhaps delayed ACKs are here too
suggested...

- Joris

"Tauno Voipio" <tauno.voipio@iki.fi.NOSPAM.invalid> wrote in message
news:DfNMc.90$Y87.50@read3.inet.fi...
>
> "Will" <wv9557@yahoo.com> wrote in message
> news:4a885870.0407241853.522338cf@posting.google.com...
> > "Joris Dobbelsteen" <none.of@your.business> wrote in message
> news:<41027803$0$147$18b6e80@news.wanadoo.nl>...
> > > When working with TCP/IP on a device with only few memory, you should
be
> > > aware of the send and receive windows used and the optimizations to
> reduce
> > > network traffic (delayed ACKs).
> > >
> > > I've seen an implementation with TCP/IP that had little memory
available
> and
> > > here the window was the limiting factor for communication with a
> (Windows)
> > > PC.
> > > Basically, the sent window of the device was much smaller than the
send
> > > window, so the data send a head was little (only 8 or 16KB, while the
PC
> has
> > > a window of at least 64KB). There is an optimization (turned on by
> default
> > > in Windows) that only sends ACKs at predefined time intervals (or when
> the
> > > receive window reaches its capacity). The effect was that the window
was
> > > partially filled (embedded device was out of memory) and needed to
wait
> a
> > > long time for the ACKs from the PC (which are sent every 200ms).
> > > So it ran over 100Mbps and, due to memory limitations, only reached
800
> > > kbps! It worked, but ensure you have enough memory...
> > > Of course turning off the optimization on the PC so ACKs are send
> > > immediately helped a bit, speeding it up an order of a magnitude!
> > >
> > > Hope this illustrates the memory demands TCP makes to actually get
> decent
> > > performance...
> > >
> > > - Joris
> > >
> >
> > Interesting observation. I wonder if sending little packets much smaller
> > than Ethernet can handle, say 200 octet packets will trigger the
> > ACKing mechanism on the receiving side. After all, doesn't telnet
> > ack every single character?
> >
> > Will
>
> There is usually an echo with a piggy-back ACK. A single keystroke
> generates (if the line mode is off) three segments: the initial character,
> the echo with ACK, and the ACk of the echo.
>
> For bulk transfer with small segments, such as Web pages, there can
> be a delay before a segment is ACKed, to provide the browser end
> the opportunity to piggy-back some data with the ACK. If the sending
> end waits for the ACK, this will slow the transfer noticeably. OTOH,
> sending without waiting for the ACK makes it necessary to store all
> un-ACKed data at the sending end.
>
> Tauno Voipio
> tauno voipio (at) iki fi
>
>
>