DATAGRAM vs VIRTUAL CHANNEL
A very basic concept is enforced by TNC operation as the first order of integrity. When the TNC detects that packets are not complete they are dropped, incomplete packets are not forwarded to the computer for processing. Yes, some TNCs have a parameter that causes incomplete packets to pass to the computer anyway, and that is good for experimentation but not for normal traffic handling. When data is passed ot jnos - don't pass partial packets.
The AX.25 specification provides for two modes of communication. The default UI or broadcast utilizes no data integrity and the sender simply hopes the recipient got the message in tact. The other mode I utilizes checksum to verify received data is identical to transmitted data. These modes serve their purposes well. Mode UI is used for when inaccurate content is of minimal consequence as in ID broadcast , and Mode I is used when data integrity is important to force a packet to be retransmited when an error is detected.
The TCP/IP specification provides similar features in handling data as does the AX.25 spec, however as you might expect there are more options in this protocol. For jnos, TCP/IP is passed over the AX.25 subnet using encapsulation. The integrity checking to honor both specs can be redundant (even useful) and this gives rise to the option of DATAGRAM / VC. The VC option applies a redundant data validation thus it is rare for TCP/IP to detect errors. The cosequence of this choice is to place some additional overhead into data transport activity, but jnos has opportunity to find and repair errors in smaller and quicker increments.
When IP is carried over AX links, the practice of encapsulating the IP packet is utilized, and the result is often that the larger IP packet is fragmented for transport by the AX.25 packet. In the default "datagram" mode, TCP/IP traffic is carried over the AX.25 network by UI frame without data integrity services. In the "vc" (Virtual Connect) mode a node-to-node channel is established using AX.25 I frames that includes data integrity protection before the TCP/IP traffic is de-encapsulated and reconstituted into the TCP/IP packet.
The more common DATAGRAM option reserves IP data validation for the TCP/IP level in the stack. That is to say if validation is desired on the TCP/IP traffic it is done after encapsulation. The consequence of this choice is that retransmission of data may require many AX packets to accomplish. On a busy or marginally reliable radio link the datagram option may suffer from large blocks of retransmitted data.
The choice of DATAGRAM vs VC is an optimization issue discussed in TuneBufWin page. Start there to set some basic parms, then progress to selecting some timer valuse to impact processing. Both protocol utilize similar techniques to detect and correct missing or errored data on the receiving end of a data link. Please refer to various texts for descriptive details. Also please expect that the two protocols may interact adversely when encapsulation is used.
The choice of datagram mode is pretty straight forward, TCP/IP protocol handles errored and missing data by handing it to AX.25 for transmission. The choice of VC on the other hand forces the TCP/IP protocol to duplicate features and therfore must be adjusted to not work too fast prior to AX.25 corrected errors being received. The consequence of similar time constants is to clutter the data channel with duplicated data and bring transfer to a standstill.
The parameters of IRTT, T..., [tbd]