From: karn@chicago.qualcomm.com (Phil Karn)
Newsgroups: rec.radio.amateur.policy
Subject: Re: HF Packet and a question...
Date: 12 Aug 92 21:09:26 GMT
Organization: Qualcomm, Inc

In article <1992Aug8.143900.21419@ke4zv.uucp> gary@ke4zv.UUCP (Gary Coffman) writes:
>Yes Phil, that's what I said too. Keep the pipe full. Have concentrator
>nodes at each end with window sizes of 309 kilobytes. And then you have
>a 1200 baud point to point transcontinental link with an effective baud 
>rate of 600 baud, round trip time of 12 minutes and windowing time of 68 
>minutes.  That's a bit longer than your 37 milliseconds, but so what,
>it's still better than the average forwarding time on the current network.

Who said anything about "concentrator" nodes?  The end nodes
themselves should be responsible for all end-to-end flow control and
acknowledgment mechanisms.  A packet network just relays packets. It
stores them only when it must because an outbound link is busy.

Like I said, for the purposes of protocol design it's not the absolute
value of the delay that matters but the number of bits that are in
flight at once. Both gigabit networks and very long store-and-forward
packet radio networks may need new protocols (or suitably modified old
ones) to require fewer round trip delays to conduct a given
transaction.  With the basic TCP mechanisms it shouldn't take more
than 3 one-way trip times to complete a transaction like sending a
mail message. Right now though you have the problem that most SMTP
implementations run in lockstep. With no real change to the basics of
the protocol it ought to be possible to send an entire SMTP transfer
stream in a single TCP segment with a SYN on the front, and the other
end would then send back all its responses in a SYN+ACK segment. Then
the sender sends a final ACK. If you built a connectionless mail
transport protocol you wouldn't need the last message; you could do
the whole thing in one round trip time.

You do need lots of buffering at transit nodes in a high
bandwidth*delay network. In the theoretical worst case, you'll need as
much buffering as the sum of all the transport protocol flow control
windows using a particular node, and this can be pretty large. But the
law of large numbers helps out here, i.e., the average buffer
requirements are much smaller than the worst case peak.  In the
relatively rare event that a buffer overflows, you just use your
reliable transaction transport protocol to retransmit from the end.

>There's a bit more to this traffic 
>flow analysis than you indicate. Real message flows don't all originate 
>at a single point on the East Coast and all travel to a single point
>on the West Coast. Message originations and destinations are diffused 
>across the entire country. The topology of the network starts getting 
>quite complex and the data flows don't keep the pipe full in most cases 
>while overflowing it in others.

Quite true, traffic flows in a real network are very complex.  This is
an ongoing research area, but I'm convinced that practical solutions
exist, especially given cheap RAM.

I'm not saying that a continental VHF store-and-forward network will
give acceptable performance; the store-and-forward delays alone would
be pretty objectionable. But there's another potentially useful
approach: "cut through" packet switching. In "cut through" switching,
a switch begins to forward a packet as soon as it can make a routing
decision, i.e., as soon as it receives the destination address,
assuming the output link is idle. It doesn't have to wait for the
entire packet to be received. Obviously this requires each node to
operate in full duplex, so you'll at least require a couple of
channels in a frequency reuse pattern.

Phil
Newsgroups: rec.radio.amateur.policy