| |
ZL3AI > APRDIG 25.07.03 08:57l 199 Lines 7949 Bytes #999 (0) @ WW
BID : 1666-ZL3AI
Read: GUEST
Subj: TAPR Digest, Jul 22, 7/7
Path: DB0FHN<DB0RGB<OK0PPL<DB0RES<ON0AR<VK6HGR<ZL2BAU<ZL3VML
Sent: 030724/1127Z @:ZL3VML.#80.NZL.OC #:4921 [Chch-NZ] FBB7.00i $:1666-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: Reality check needed re uptimes and a soapbox rant, like it or
not.From: "AE5PL Lists" <HamLists@ametx.com>
Date: Tue, 22 Jul 2003 22:41:35 -0500
X-Message-Number: 42
>-----Original Message-----
>From: Gregg G. Wonderly [mailto:gregg@skymaster.cytetech.com]
>Posted At: Tuesday, July 22, 2003 9:58 PM
>Subject: [aprssig] Re: Reality check needed re uptimes and a
>soapbox rant, like it or not.
>
>The biggest problem with this premise is that it is not true. It is
>rediculous to drop a connection based on backlog. If you are
>doing this at
>the application level, then you are 1) ignoring TCPs ability
>to do this for
>you and 2) don't understand how to build a fault tolerant
>distributed system.
>The servers should flush the queues and maintain the
>connection until TCP says
>it's gone. This can be a long time, if the machine is
>removed from the
>network completely and noone is sending back ICMP messages
>about the host
>route being lost.
I disagree. Regarding #1, the application is using TCP's ability to handle
buffering. The problem is that certain TCP/IP stacks do not execute the
timeout property properly (a simple search will bear this out concerning
numerous bugs in various stacks). Regarding #2, understanding how to build
a fault tolerant distributed system and implementing a compatible system
are two different issues and the latter is what has been done to-date.
IMO, servers should not flush queues. This causes data loss without the
client being aware of a problem. One problem stated many times in the past
is "why doesn't my packet show up". This still occurs, but is more readily
traceable. Simply dropping (flushing) packets in the name of maintaining a
TCP connection removes one layer of reportability. Using excessive
buffering for connections that can't keep up can cause loops (with the
current APRS protocol and the APRS-IS transport method).
Finally, relying on ICMP means that the clients and servers can handle ICMP
messages (many firewalls and NAT routers have ICMP blocked).
Your recommendation for proxy server applications on every client and a
fully distributed, fault tolerant system are commendable. However, I
believe (and have stated in the past) that any recommendations such as this
should be addressed as looking at APRS-IS V2, with consideration given not
only to the best network solution but also things like how easily it can be
implemented, how well and quickly will it be accepted, what is the impact
on the RF APRS networks, etc. It is easy to diss an existing design as
"ill designed" but the question then becomes "Does what you recommend as a
replacement meet all of the requirements that the current design does?" The
question is valid. As Sony found out many years ago, sometimes the best
design doesn't meet an important requirement causing its rejection by the
masses (Beta vs. VHS).
This is simply to say "progress can be made without disparaging
developments made previously". It also goes the other way, "Current
designs can always be improved upon." As users, sysops, and authors, we
each make the decision whether the pain demands the gain or the gain isn't
worth the pain.
73,
Pete Loveall AE5PL
pete@ae5pl.net
----------------------------------------------------------------------
Subject: RE: Reality check needed re uptimes and a soapbox rant, like it or
not.From: "Dave Anderson" <dandersn@citicom.com>
Date: Tue, 22 Jul 2003 23:43:22 -0400
X-Message-Number: 43
Gregg,
Glad you joined this thread!
>The biggest problem with this premise is that it is not true. It is
>rediculous to drop a connection based on backlog. If you are
>doing this at
>the application level, then you are 1) ignoring TCPs ability
>to do this for
>you and 2) don't understand how to build a fault tolerant
>distributed system.
I can agree with you here. I have to point primarily to "1". Pete can
explain in more detail, it's all about packet duplication issues in the
current ARPS spec.
>The servers should flush the queues and maintain the
>connection until TCP says
>it's gone. This can be a long time, if the machine is
>removed from the
>network completely and noone is sending back ICMP messages
>about the host
>route being lost.
Correct. I can drop a link between a server via telnet for 10 minutes, and
come back, and re-establish the link if nothing has changed since the close
message nak/ack never arrived. The catch here is that the APRS spec doesn't
seem to allow for this implementation of the TCP protocol, or that's what
i've been told.
The implementation of APRS currently also, based on this premis, is also
extremely packet heavy for the amount of traffic it truely moves.
This all really boils down to the original design of moving the packets some
7 years ago. I don't think the scale of todays operations were even a
glimmer in anyones mind at the time.
>protocols. What is at issue is that the APRS stream is ill
>designed. A
Agreed, whole heartedly.
>If you look back at many of the serial data transfer
>protocols such as kermit,
>and before that, X/Y/Z modem, you will find design principals
>which help to
>make data transmission bandwidth efficient.
Ohh, that brings back memories. Look at the performance between Xmodem and
Zmodem. About as close to day and night as you can get for a async transfer
method, yet ultimately, they get the same job done.
>I've discussed my thoughts and ideas on an APRS-IS backbone
>that completely
>eliminates the TCP path between nodes by letting the user put
>a proxy server
>on their machine that their existing software can connect to
>with a simple TCP
>stream. The proxy server then utilizes the distributed
>systems technologies
>that work to create a reliable stream environment. Leasing
>comes into play
>whereby the proxy reserves its right to stay connected to the
>server. A
>windowing mechanism would allow the proxy to acknowledge the
>current sequence
>in the window. This would let the server know that data is
>still flowing. It
>could then not burden the kernel with too many outstanding
>packets. Bursty
>network performance caused by rerouting, router rebooting and
>other issues can
>create problems if you are not using end to end
>acknowledgements. Both
>windowing and leasing (timeouts) are important parts of data
>distribution over
>long haul, unreliable networks.
Agreed. A distributed streaming system would make the most sence.
I am just not sure how at this time in the game any major re-work of APRS-IS
could take place given the different software packages that exist.
Improvments in the TCP protocol implementation could be made, but i'm not a
developer, that's one layer higher in the OSI model than I work in, so i'll
have to pawn that off to the experts of that arena. <grin> (i'm the first
to admit when i'm in a area outside my expertise)
>I think the argument was about connection reliability not
>'real-time'. These
>are distinctly different issues...
Yes, they are. Just seems that reliability and real time seem to go hand in
hand with APRS, or at least they get intertwined.
>>Bottom line. There is no perfect system.
>
>Currently there is no perfect system, but there can be a
>system that is much
>better than what currently exists, and people trying and
>experimenting with
>new concepts is how we will achieve a better quality service...
What we need is a distributed system that has mulitiple paths so that
redundancy can exist simply - with a duplicate checking system that can
account for lag.
Lord knows, if my router decided to catch a route from each one of my eBGP
peers and duplicate it 5 minutes later every time it got one we'd all be in
trouble --- bottom line --- there are other systems in place that exist that
prove APRS-IS could be handled better, even in it's real time environment.
Seeya,
Dave
KG4YZY
www.aprsfl.net
---
END OF DIGEST
Read previous mail | Read next mail
| |
