| |
PA2AGA > TCPDIG 07.01.98 23:12l 171 Lines 6866 Bytes #-10109 (0) @ EU
BID : TCP_98_2B
Read: GUEST
Subj: TCP-Group Digest 98/2B
Path: DB0AAB<DB0FSG<DB0SL<DB0RGB<DB0MAK<DB0SON<DB0ERF<DB0HSK<PI8DRS<PI8DAZ<
PI8GCB<PI8HGL<PI8VAD<PI8VNW
Sent: 980107/1903Z @:PI8VNW.#ZH2.NLD.EU #:6910 [Hoek v Holland] FBB5.15c
From: PA2AGA@PI8VNW.#ZH2.NLD.EU
To : TCPDIG@EU
Received: from pa2aga by pi1hvh with SMTP
id AA376 ; Wed, 07 Jan 98 18:19:56 UTC
Received: from pa2aga by pa2aga (NET/Mac 2.3.65/7.1) with SMTP
id AA00005804 ; Wed, 07 Jan 98 19:07:44 MET
Date: Wed, 07 Jan 98 19:05:17 MET
Message-Id: <tcp_98_2B>
From: pa2aga
To: tcp_broadcast@pa2aga
Subject: TCP-Group Digest 98/2B
X-BBS-Msg-Type: B
------------------------------
Date: Tue, 06 Jan 98 15:46:00 -0000
From: mikebw@bilow.bilow.uu.ids.net (Mike Bilow)
Subject: TCP/IP over radio
Alan Cox wrote in a message to Mike Bilow:
AC> There are several fairly broken assumptions in this IMHO.
AC> The first one is that tcp acks pile up. Thats only the case
AC> if the AX.25 layer isnt feeding flow control information
AC> back to a TCP layer that can handle it.
I do agree with Alan's comments, but it is worth pointing out that most of the
existing software used for Amprnet does exhibit exactly the behavior
described.
While this is really an implementation fault, it is a common one.
AC> VC is not the answer however, DG mode with FEC to bring the
AC> errors down to < 1% per hop hub-hub is the answer. This
AC> sounds quite a step towards it
A more serious practical problem, unfortunately, is that the reliability of a
chain of links is essentially dependent upon the weakest link. In order to
achieve predictable rtt measurements, all of the links need to be at roughly
the same level of reliability. Otherwise, frames will start to pile up in
queue waiting to cross a bad link.
It is one thing to worry about frames piling up in your own protocol stack on
the same machine, but quite another to worry about a similar condition at
another machine on the path. If a particular link, for example, passes 95% of
frames within 5 seconds of arrival and the other 5% within 90 seconds of
arrival, this is going to produce an awfully funny-looking rtt measurement no
matter how you attempt to discover it. The only rememedy for this kind of
thing is to have a network message sent back from the pile up, something along
the lines of ICMP Source Quench, which has its own dangers in addition to
adding to the load on a congested network.
It therefore stands to reason that the network will behave far more
predictably
with regard to rtt, which determines retry timers, if frames are simply
discarded rather than piled up. An individual link which can get 95% of its
frames across within 5 seconds should not be configured to retry the remaining
5% of its frames for 90 seconds. Instead, it should be configured to drop
these frames on the floor.
-- Mike
------------------------------
Date: Tue, 6 Jan 1998 19:55:44 +0000 (GMT)
From: Alan Cox <alan@cymru.net>
Subject: TCP/IP over radio
> the same machine, but quite another to worry about a similar condition at
> another machine on the path. If a particular link, for example, passes 95%
of
> frames within 5 seconds of arrival and the other 5% within 90 seconds of
Which you don't do - as indeed you say below
> matter how you attempt to discover it. The only rememedy for this kind of
> thing is to have a network message sent back from the pile up, something
along
> the lines of ICMP Source Quench, which has its own dangers in addition to
> adding to the load on a congested network.
If your higher level protocols work properly you don't need source quench,
tcp works fine on the absence of acks to measure probable packet loss. The
other alternative I've seen that does work is to set a congestion bit in
an existing header and have the receivier also ack such frames with the
bit set too
> with regard to rtt, which determines retry timers, if frames are simply
> discarded rather than piled up. An individual link which can get 95% of its
> frames across within 5 seconds should not be configured to retry the
remaining
> 5% of its frames for 90 seconds. Instead, it should be configured to drop
> these frames on the floor.
Definitely.
------------------------------
Date: Tue, 06 Jan 98 21:21:29 MET
From: iw1cfl@iw1cfl.ampr.org (Michele Debandi)
Subject: TCP/IP over radio
Hello all,
I have just read about the question of the usefulness of VC mode over
radio. I think that in a strong IP-only environment this is not a good
choice. I notice some facts:
- On ATM systems the most used protocol il AAL 5, that is a connectionless
service (is not assured that the cell you transimit arrives at the other
level);
- On public networks, interconnecting LAN, is preferred Frame relay
network (actually in italy is almost FR-over-ATM) rather X.25 network
even if the latter has a volume taxation, rather than a time-taxation;
So why if the rest of the world is abandoning the idea of a connected
L2 layer under IP, we have to stay to an L2 connected service to transmit
tcp?
The big problem I see on ampr IP network (and on digital data transmisson)
is due that ax.25 doesn't make a forward error correction: so
you loose a 256 byte packet even if only a bit is wrong.
In fact ATM/FR/X.25 runs on optical fibers with a very low error rate,
but if we (using FEC) could decrease the hop-to-hop error ratio, the
end to end acknowledge of TCP is sufficient.
Anyway, if an IS have to make hop to hop ack, it must have sufficient
memory and processing power to deal with a retraqsmission queue for every
VC that uses it, rather than have ony one queue for port. At 9600 bps
is not a concern, but on an high spped microwave link thi could slow down
the transmission sightly.
Maybe is more useful thing about an 'amateur frame relay', with FEC
and if an IS receives a bad frame, simply drops it.
73
Mike
------------------------------
Date: Wed, 07 Jan 1998 17:30:19 +1100
From: Terry Dawson <terry@perf.no.itg.telstra.com.au>
Subject: Wireless WearComp
Steve Mann wrote:
> A small battery-powered rig is preferable. I recommend the Kantronics
> TNC if you're planning on running TCP/IP over the radio, as that's a good
> place for a beginner to start. If you're more adventurous, or get tired
> of this, you might want to build a WA4DSY system (above is a G3RUH).
> The former has the advantage that it will work at 19k2 or lower rates
> such as 1200bps. Thus you might use it with a standard HT at 1200bps
> for a while, and then upgrade to 19k2 by hacking a Micor or Tekk, opening
> up the front end a little.
If you run linux, and your palmtop/laptop has an inbuilt soundcard
you can dispense with the TNC completely and just run the kernel
based soundmodem driver which will happily do a variety of modem
standards directly into your favourite handheld transciever.
Terry
--
Linux: standard and fully integrated support for Amateur Radio protocols
"Penguinitis is contagious". http://www.linux.org.au/
------------------------------
End of TCP-Group Digest V98 #2
******************************
Read previous mail | Read next mail
| |
