• TuneIrttAck

Select Protocol Setting

Three of jnos protocols include a secure variety of communication that requires a receipt of an acknowledgment that good data has arrived at the destination. Until the ACK arrives, the protocol simply stacks any new outgoing data in a transmit queue. After the ACK is processed, the next packet or frame of packets is taken from the queue and sent on its way toward the destination which might be many hops from the source.

The three varieties in consideration here are AX.25 level 2 that produces the "I" packet, the TCP, and the NET/ROM, protocols. These protocols are configured separately, but each works in a similar fashion. Each protocol keeps a record of the time a packet leaves the source, computes data about the rtt (round trip time) when the ACK arrives, and sends repeat, or duplicate, packets upon deciding it is not likely to see an ACK therefor the last packet [or ACK] sent must be "lost" somewhere in the network.

Now there are two main reasons that a repeat packet is sent;

• First, something has in fact caused the packet to be lost and the main reason is a collision or interference with the transmission over radio or other multi-node media. Once a packet is lost, sending another is a good thing.

• Second, something has delayed a packet or the ACK that would eventually arrive at destination because it is not in fact lost, however the time has arrived when jnos has to make the decision about sending a duplicate packet to restore the communication link integrity. To send a duplicate packet before the ACK has arrived is not a good thing because the duplicate simply adds to the clutter that is delaying the ACKs arrival. This makes matters worse.

Now the sysop has opportunity to monitor for these conditions and adjust the configuration so as to improve communication efficiency. It is useful to know these protocols work from end-to-end but are subject to effects on every hop between the two ends. Mid-point stations in the route from source to destination play no part in determining what reason is at play to disrupt data transfer.

Each protocol computes values for srtt (statistical mean rtt) and mdev (mean deviation in rtt times) to drive the packet retransmission function. The calculations are not truly statistical, but are a reasonable approximation. The srtt and mdev values are used in a formula to set a timer for "time allowed before taking remedial action": that is resending the packet or giving up the attempt to communicate. The formula includes TIMERTYPE method, because the protocols have a variety of fall-back methods described with their configuration parameters. The formula also includes BLIMIT to cap the maximum time between retry attempts. After a number of RETRIES the protocol gives up and closes the link until the protocol either reopens the link and starts again from the beginning or notifies the sysop and quits completely.

The sysop has opportunity to watch srtt and mdev values by monitoring the control blocks for each protocol. In the case of TCP, the "tcp irtt" subcommand displays historic values. When these values seem out-of-normal ranges, the sysop can review the packet trace for the link to troubleshoot using the detail [but certainly this is tedious?]. When duplicate packet counts [retries] become large, the link configuration needs repair. The type of repair depends on circumstances.

The AX.25 protocol carries TCP/IP and NET/ROM by encapsulation, therefor IRTT for AX.25 must never be larger than irtt for the other protocols. Often it should be significantly smaller. When other protocols are encapsulated in AX.25 level 2, irtt, timertype, blimit, and retries, all must be selected to allow AX25 to play-out its methods BEFORE the upper protocol initiates its own security methods. Duplication by the second protocol only adds clutter and does not add security to the link,

The values set for irtt and the other parameters are effected by the speed of the route. Internet is several orders of magnitude faster than 300B packet, thus a route that includes one hop over 300B will log-jamb and die if it is configured for internet only.

The commands used to modify the site default values from pre-compiled values are:

These values may be reset on each connection using the IFCONFIG command.

Some observed starting values for irtt to consider as a starting point:

• on the host, 3 to 10ms
• on a LAN, 7 to 50ms
• across Internet, 25 to 250ms
• over 9600B packet link, [tbd]
• over one 1200B packet link, 5000 to 15000ms
• over 300B packet, consider something else?
• over HF Pactor, 15000 to 50000ms

• long route & many haps, multiply value by hop count

As of jnos2.0f, when irtt is used to set srtt, then mdev is set to zero. A zero mdev is not perhaps reasonable, but mdev is certainly unknown. A common formula for the wait time prior to resendin a packet is:

• wait = fall-back-factor * (srtt + (4 * mdev))

This formula tends to yield short retry times when mdev is small, thus it is recommended to error on the high side when picking irtt to avoid excessive retries early on while jnos computes a reasonable experience value for both srtt and mdev. Experience suggests that multiplying local observed values by three is quite workable.