| |
ZL3AI > APRDIG 26.07.03 09:16l 267 Lines 10228 Bytes #999 (0) @ WW
BID : 1669-ZL3AI
Read: GUEST
Subj: TAPR Digest, Jul 23, 1/8
Path: DB0FHN<DB0RGB<OK0PPL<DB0RES<ON0AR<VK6HGR<ZL2BAU<ZL3VML
Sent: 030725/1323Z @:ZL3VML.#80.NZL.OC #:4977 [Chch-NZ] FBB7.00i $:1669-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
TAPR APRS Special Interest Group Digest for Wednesday, July 23, 2003.
1. RE: Reality check needed re uptimes and a soapbox rant, like it or not.
2. RE: Reality check needed re uptimes and a soapbox rant, like it or not.
3. Re: Reality check needed re uptimes and a soapbox rant, like it or not.
4. Re: Running aprs in the car with a laptop
5. Re: Internet feed settings???
6. Re: Running aprs in the car with a laptop - Use DC-DC conv!
7. Re: aprssig digest: July 21, 2003
8. Add X-Port to TNC?
9. APRS Future
10. Re: Reality check needed re uptimes and a soapbox rant, like it or not.
11. Trucks with 7 and more Wides
12. I-gate question.
13. RE: Trucks with 7 and more Wides
14. Re: Trucks with 7 and more Wides
15. Re: Trucks with 7 and more Wides
16. Re: APRS Future
17. Re: APRS Future
18. Re: APRS Future
19. Disdplay for Cheap
20. Re: APRS Future
21. GPS thoughts
22. Re: APRS Future
23. Re: APRS Future
24. RE: Reality check needed re uptimes and a soapbox rant, like it or not.
25. DeLorme Earthmate and APRS
26. Re: GPS thoughts
27. Re: Running aprs in the car with a laptop - Use DC-DC conv!
28. RE: Running aprs in the car with a laptop
29. RE: Add X-Port to TNC?
30. Re: GPS thoughts
31. Mobile power
32. Stations Heard: Portable in Bimini /C6A
33. Re: Running aprs in the car with a laptop
34. Re: HF data question
35. Re: APRS IP address
36. Re: HF data question
37. Re: Running aprs in the car with a laptop
38. DOS decoding of raw TNC data
39. Re: DOS decoding of raw TNC data
40. Re: running a laptop in the car
41. PHGr just got better! It's PHGra
42. RE: Reality check needed re uptimes and a soapbox rant, like it or not.
43. PSR deadline
44. Re Stations Heard:Portable in Bimini/C6A
45. Re: running a laptop in the car
46. RE: RAgeo, a low cost GEO bird
47. Re: Trucks with 7 and more Wides
48. Re: Mobile power
49. Re: Re Stations Heard:Portable in Bimini/C6A
50. Re: Trucks with 7 and more Wides
51. Re: Trucks with 7 and more Wides
52. Re: Master HF TUNE station--was Bimini
----------------------------------------------------------------------
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: 1
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
----------------------------------------------------------------------
Subject: RE: Reality check needed re uptimes and a soapbox rant, like it or not.
From: "Dave Anderson" <dandersn@citicom.com>
Date: Wed, 23 Jul 2003 00:04:56 -0400
X-Message-Number: 2
>You are absolutely correct. That is why I didn't mention
>anything about
>drops. I have watched (always with a subtle smile) Cisco claim that
>VOIP over the Internet was going to replace the class 5 and 4 switches
>(the switches at the telephone companies' central offices and
>those that
>connect the CO's to the long distance carriers). For the reasons you
>stated, something major will have to change for the VOIP over the
>Internet to even begin making inroads.
I do have to say, being a user of the AVVID system of Cisco's, that with the
appropriate QOS services enabled that VOIP works very well in a WAN
environement. Our entire phone system is IP based, and I use both soft
phones (windows application that emulates a phone on your PC) and the 7960
IP phones. All terminate into a router some 100 miles from my office that I
have co-located at a CO (which goes to a PRI line into their 5E switch 3
rows over in the CO).
The days of it replacing POTS overall, well alot has to change before that
can happen. :) QOS would have to be honored network wide. Given most
providers can't even agree on consistant peering arangements, that seems to
be almost a fantasy. It's great for a network when you own and control it
end to end though <grin>.
>The near real-time nature of APRS-IS not only puts a bandwidth load on
>the ISP; it puts a packet load on the ISP's router(s). These
>are just a
>couple of reasons why one cannot simply look at the average
>bandwidth of
>the data portion of an APRS-IS feed and make definitive
>statements about
>the affect on the connection. Like your statement, this an
>explanation
>for those following this thread, not a jab as you have noted
>this in the
>past.
Yes, as i've noted in the past about packet requirements <ducking> hehehe.
Here's a gander at my ethernet port facing the APRSFL server with 92 users
online right now:
30 second input rate 696000 bits/sec, 819 packets/sec
30 second output rate 243000 bits/sec, 296 packets/sec
Compare that to the T1 feeding a customer of mine:
1 minute input rate 522000 bits/sec, 148 packets/sec
1 minute output rate 953000 bits/sec, 165 packets/sec
The bandwidth usage is almost a non-issue with the APRS port - but the
packet count for well 1/3 of the bandwidth usage is almost 4 - close to 5
times higher. I have no problems with it --- but I know for a fact other
Sysop's have had problems with it.
This is what I think is probably one of the biggest problem with servers
operating with APRS in it's current working format.
SysOp's may feel they have the bandwidth, but depending on the router behind
the server, things could work differently for that server depending on how
much horsepower that router has and -if- their ISP is using a packet
switching system in that router that best utilizes it's power. Many smaller
ISP's don't realize the benefits of CEF routing, for example, in the later
builds of IOS. It's a -HUGE- improvement in a routers ability to move
packets per second over just standard fast-packet switching.
Back on the point (wow, I get side tracked easy) - there's many factors that
need looked at.
Seeya,
Dave
KG4YZY
www.aprsfl.net
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
