PPP and flow control
Ralph Hayon
Our system allows a computer (i.e., Windows machine with
TCP/UDP/IP stack) to be connected to our radio unit via PPP over
a serial link. (Our wireless subscriber unit has a 9 pin serial
interface).
In reading the PPP spec we did not notice the concept of flow
control. Since we allow UDP messaging over this serial link we
don't understand how flow control is achieved after the PPP
open has been completed.
Does anyone have any knowledge in this area that could help us
out?
Best Regards,
Ralph Hayon
Geotek Communications
201-930-9305
201-930-9614 (fax)
Vernon Schryver
>We are designing a wireless data system that is mobile-IP based.
>
>Our system allows a computer (i.e., Windows machine with
>TCP/UDP/IP stack) to be connected to our radio unit via PPP over
>a serial link. (Our wireless subscriber unit has a 9 pin serial
>interface).
>
>In reading the PPP spec we did not notice the concept of flow
>control. Since we allow UDP messaging over this serial link we
>don't understand how flow control is achieved after the PPP
>open has been completed.
The answer is that UDP/IP/PPP flowcontrol is achived in exactly the same
way that UDP/IP/Ethernet, UDP/IP/FDDI, UDP/IP/T1, UDP/IP/PPP/v.32-modem,
or UDP/IP/wet-string flowcontrol is achieved.
On the other hand, what kind of "flow control" is needed in such a
circumstance? The application had better not try to send a few GByte
per hour and should throttle itself as required. But I hope the wireless
box would buffer a few packets, like any other PPP/slow-medium box, and
discard any excess. There is no evident need for flow control between
the wireless transmitter and the wireless receiver.
I have heard incredibly bad or funny (depending on your view of standards
committees) reports of the authentication, flow control, fragmentation,
error detection and recovery, and everything else that belongs in an
upper layer that IEEE 802.11 proposes to standardize.
Vernon Schryver v...@rhyolite.com
James Carlson
In article <3u1bgm$18e$1...@mhafc.production.compuserve.com>, Ralph Hayon <73707...@CompuServe.COM> writes:
|> We are designing a wireless data system that is mobile-IP based.
|>
|> Our system allows a computer (i.e., Windows machine with
|> TCP/UDP/IP stack) to be connected to our radio unit via PPP over
|> a serial link. (Our wireless subscriber unit has a 9 pin serial
|> interface).
|>
|> In reading the PPP spec we did not notice the concept of flow
|> control. Since we allow UDP messaging over this serial link we
|> don't understand how flow control is achieved after the PPP
|> open has been completed.
|>
|> out?
PPP doesn't have any concept of flow-control, because it's a network
data-link-level protocol. Reliability and flow control are handled by
upper-level protocols such as TCP in a network. UDP, of course, is not
reliable and has no flow control whatsoever.
You might want to run out to the library or bookstore and grab a copy of
a good networking text (like Comer's) before trying to implement flow
control over UDP ...
(I don't mean that to sound like a flame, but the question you asked
reveals a bit of a flaw in your architecture.)
--
James Carlson <car...@xylogics.com> Tel: +1 617 272 8140
Annex Software Support / Xylogics, Inc. +1 800 225 3317
53 Third Avenue / Burlington MA 01803-4491 Fax: +1 617 272 2618
WAWA
>We are looking at the use of TCP/IP over radio for SCADA telemetry and
>control). We would like to allow mobile users to access this network
It looks as if I lost my signature file, and that posting was
anonymous. Apologies.
Ian Wiese http://www.iinet.net.au/~ianw/
Water Authority of Western Australia ia...@iinet.net.au
629 Newcastle St, Leederville, 6007 Ph Hm 619 4487487 Wk 619 4202610
Western Australia Fax 619 4203175
WAWA
>In article <3u1bgm$18e$1...@mhafc.production.compuserve.com>, Ralph Hayon <73707...@CompuServe.COM> writes:
>|> We are designing a wireless data system that is mobile-IP based.
>|>
>|> Our system allows a computer (i.e., Windows machine with
>|> TCP/UDP/IP stack) to be connected to our radio unit via PPP over
>|> a serial link. (Our wireless subscriber unit has a 9 pin serial
>|> interface).
>|>
>|> In reading the PPP spec we did not notice the concept of flow
>|> control. Since we allow UDP messaging over this serial link we
>|> don't understand how flow control is achieved after the PPP
>|> open has been completed.
>|>
>|> Does anyone have any knowledge in this area that could help us
>|> out?
We are looking at the use of TCP/IP over radio for SCADA telemetry and
control). We would like to allow mobile users to access this network
There are shortcomings in PPP for this application. PPP is not defined
over half duplex radio. (There's nothing in PPP that inherently
prevents it, but the RFC says it must be full duplex)
Also if the mobile users can talk to each other then PPP is not Point
to MultiPoint.
It is not a major effort to extend PPP to cover this situation, but it
should be done as a standard.
There is extensive discussion of these issues on the scada mailing
list. (email majo...@iinet.net.au with subscribe scada in the body
of the message.) You may find this discussion of interest.
Rich Adamson
> We are designing a wireless data system that is mobile-IP based.
>
> Our system allows a computer (i.e., Windows machine with
> TCP/UDP/IP stack) to be connected to our radio unit via PPP over
> a serial link. (Our wireless subscriber unit has a 9 pin serial
> interface).
>
> In reading the PPP spec we did not notice the concept of flow
> control. Since we allow UDP messaging over this serial link we
> don't understand how flow control is achieved after the PPP
> open has been completed.
>
Ralph,
As several folks have mentioned, "packet" flow control is the
responsibility of upper layer protocols (TCP).
In addition, hardware flow control is typically used at the serial
connection to effectively create the necessary half-duplex connection
common in two-way radio, cellular data comm, and other mobile radio
implementations. I'm sure when you look at the designation of each
pin in the 9-pin serial interface, you will find a Request-to-Send
(RTS) and Clear-to-send (CTS) hardware flow control assignments that
will block transmissions until such time as the radio channel is
available for "trasmit".
I would be concerned (and probably research) the upper layer protocol
timeout values for the software you expect to use in the Windows
communications program. If these values are relatively short (in
terms of mobile communications timing), the upper layer protocol may
timeout and request retransmissions not knowing that hardware flow
control may have not allowed a packet(s) to be transmitted due to
channel-busy conditions. The channel-busy condition is more likely
to create problems for your implementation than half- verses full-
duplex functions.
I've worked with Cellular providers to establish cellular data services
via existing cellular telephone equipment, and in many cases, the
cellular mobile Windows communications software (Netmanage's Chameleon
as one example) work just fine. Non-cellular mobile communications is
a little different, but can be implemented.
Hope that helps...
Rich Adamson
ad...@routers.com
Ralph Hayon
It appears that PPP was primarily designed from a TCP perspective
so that flow control is not an issue. But for the wireless
environment TCP has alot of overhead. Although we have designed a
mobile IP wireless data system, we plan to have the majority of
our applications use UDP with some small protocol on top of it to
make sure messages get through with acknowledgment.
Again, thanks for the input and I will followup on the book by
Comer.
Ralph Hayon
Geotek Communications
ra...@geotek.com
Vernon Schryver
>I just wanted to thank everyone for the responses.
>
>It appears that PPP was primarily designed from a TCP perspective
>so that flow control is not an issue. But for the wireless
>environment TCP has alot of overhead. Although we have designed a
>mobile IP wireless data system, we plan to have the majority of
>our applications use UDP with some small protocol on top of it to
>make sure messages get through with acknowledgment.
"TCP has a lot of overhead" is wrong. About 3 bytes/packet is a lot
less than the 28 bytes/packet of UDP/IP header. (I'm obviously talking
about VJ header compression.)
Oh, well. At least they're not using some lameo raw Ethernet nonsense.
Vernon Schryver v...@rhyolite.com