Well, yes there is a point, if you consider a byproduct of one of its features. Multilink can fragment large packets, for example the biguns you get in FTP, into small chunks. Normally is does this so it can spread the chunks evenly across two or more links.
Now, voice is sensitive to delays. So if a voice packet gets stuck behind a large FTP packet on a slow-ish link, it can be bad news. But if the FTP packet has been broken into small chunks by the multilink protocol, and if the voice packet has absolute priority, then the voice packet can slip in between two chunks of the FTP packet.
That is why autoqos can decide to make a link "multilink" even if there is only one of them.
The queuing strategy is all software, so yes your voice packet will go in front of the large "ftp" packet. Problem comes in the hardware buffer, due to the serialization delay on the serial link. The voice will have to wait until the whole "ftp" packet has been clocked on line, if the large "ftp" packet fills the hardware buffer. Thus voice will suffer from jitter and "break up".
Best practice is to implement LFI links > 768K, although I found using it on links > 512K works for me.
Options of implementing LFI includes ppp multilink, and frame-relay (FRF.12)
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...