[nos-bbs] TCP/IP over AX.25 on VC - a study

[(Skip) K8RRA]

Hi Steven...

On Tue, 2007-06-05 at 19:59 -0400, Steven Stimpson (N1OHX) wrote:

> 
>  Skip, could you explain why this is so with Jnos but not any other
> NOS, all OS's and types included?
I really don't know that this extends beyond my own site and my neighbor
sites.  The EXACT settings are perhaps one small bump on the elephants
posterior?
>  I ask because, for example,
> my Jnos runs wildly different parameters than, say, google.com. Or
> download.nvidia.com which i usually use for testing. 
SUSPICION: the use of different algorythms internally?
> I am just wondering
> what it is specifically with ip over ax.25 that requires scientific
> inspection and testing of all those parameters? 
Please don't put narrow restriction on these parms, there is a range
that probably work well.  In fact, as I said a few days ago MI-DRG has
one set that fits all.  BUT do note the use of *ONE SET* on *ALL*
members.
> Most of all,
> why do they need to be  the same at each end?
Again - there seems to be a range that work well - even though smaller
variations are "measureable".  The question of "good enough" must apply.
> 

> i am not sure one specific FTP is exactly a scientific test.
Perhaps FTP is not the best, but it does have the characteristic of a
constant demand for bandwidth over the time of transfer.  In that time
which has a dependable demand it is fairly easy to view the results...

My principal interest is in a set of parms that don't "bog down" under
multiple independent users from their viewpoint.  Slow down is OK, but
unresponsive to trivial requests drives users to another way of
communicating.  I *hope* my approach delivers on that desire too...
> 
> 

> 
>  Who is mixing UI and VC on the same node? 
I am...
The traffic south goes VC, north goes datagram - all the same frequency.
It is not unlike one station with one hard-to-reach neighbor who is
important to you...
> the concept of
> establishing a TCP/IP capable node on a specific frequency
> assumes the sysop of that node is going to provide some
> timing parameters based on documentation and common sense.
QSL
> 
> For example, on the node frequency, there will be no direct station to
> station
> transfers, this causes HTS.
[HTS? oops - unfamiliar terminology to me]
>  and you do not mix UI and VC. you assign
> each station an IP and add it to the nodes ARP tables and there you
> establish
> if that user's link is going to be UI or VC. I have never heard of a "Mix".
Am I "all *mixed* up"?
> 
> I also do not underatand why an ax.25 frame carrying IP data, should somehow
> be different from >>SNIP<< which may cause
> the
> dreaded "fragmentation".
What I saw was this:
The AX VC channel successfully delivered IP datagram, but then it would
repeat anyway.  The repeat shows up under the IP statistics, plus would
now require more delivery time.  In severe cases, I have seen the
channel just shut down from repetition...

The cause is that IP parameters are set too "impatient".  Where a
setting seems to work for datagram transport, it fails (or degrades) for
(I) channel.  The connected mode can be a bit slow - especially if the
channel is not too clear - IP just needs to wait for AX to do it's job
instead of pulling the repeat trigger.
> 

> link? It sounds to me like you are trying to pull a dump truck
> up mount washington with a ford pinto.
All you need is low gear and time...
Not one but two FTPs.  I wanted to create the situation that both ends
of the channel were trying to send data blocks simultaneously.  It
worked that way - except for the *&%# timers that cause inappropriate
repeats...
> 

> 
> Exactly what I mentioned above regarding IP timers versus
> ax.25 timers. Just because your ax.25 channel has a 7 sec
> frack to whatever it's destination is, does not mean
> that BEHIND that ax.25 connection IP data is not piling up.
Oh yes it does if the IP formula (say linear) times out for srtt and
starts the repeat cycle while AX is struggling with it's own formula and
repeat cycle to get the AX packet thru the link...

Try it - you will NOT like it...
> 
> You also have several IP connection all attempting
> to use the single AX.25 channel. ax.25 may be getting
> it's point-to-point date to it's destination in 7 sec,
> but since all those tcp sockets are sharing that connection
> they divide. And..."Shudder"..all those TCP ACKS.
YUP - the GOOD news is that jnos does keep the paths nicely separate and
delivers all those ACKS in good form.  There is no cross-channel
cluttering I guess is a way to say it?
> 

> 
>  Do that and you defeat the basic premise of TCP. you might as well
> get rid of it's checksumming features too and stop the TCP
> ACKS from taking up those 40 bytes on return.
OH MY NO...  TCP/IP is good stuff, and the guys made a good point in
their 1994 paper that VC has it's place in delivering reliable AX stuff.
I would not change a thing EXCEPT when IP lays on top of AX on VC - and
what I would change is ONLY the duplication of function in the two
protocols.  Please don't get over zealous...
> 
> 
>  I'm sorry that your scientific test did not work out as you had
> hoped,
Actually - it did work out.  I now have some sense of how to apply
limits to this configuration that were not available (to me) prior to
this.  The results surprised me a little.
>  but I'm not quite sure that optimizing Jnos in it's
> entirety, and especially that hacking the TCP timing parameters,
> is going to help the nos community as a whole. It may help you in your
> very own and personal perception of the documents, but in the
> grand scheme of things it adds more complexity, and worse, it makes Jnos
> fall away from the specific protocol specification to which
> is was designed. those TCP timing parameters work fine on the internet
> and everywhere TCP is used, sorry if they do not work with your own
> personal set of rules you have established on your RF net. maybe
> is has more to do with  the structure of your own RF net when it is
> loaded down with a put,get,finger,ping, and even smtp? Also is your
> RF net a 9600, 19.2k or even higher link?
Good ol' 1200B.

You are very much correct that our community is not going to now run out
and reset configuration parms.  My present purpose is to test my finding
with the experience of others like yourself.  And if I can help someone
else avoid my frustration I will be delighted.
> 
>  That might help, but then the same problem arises, you do not
> have your own personal specification of the TCP
> protocol to use at your disposal, so things may still go awry.
YUPPER - I'm just a user who has the "twiddles" supplied by the
developers at his disposal.  Their job was to lay out the playing field.
My job is to get the football from one end to the other as quickly as I
can without stepping in something.

Thanks for your review - it is a great help.
> 
> Steven - N1OHX
> 
> 
> _______________________________________________
> nos-bbs mailing list
> nos-bbs at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/nos-bbs

73
de [George (Skip) VerDuin] K8RRA k