如果線路速率是9600 b/s，而一個字節有8 bit，加上一個起始比特和一個停止比特，那麼線路的速率就是960 B/s（字節/秒）。以這個速率傳輸一個1024字節的分組需要1066 ms。如果我們用SLIP鏈接運行一個交互式應用程序，同時還運行另一個應用程序如FTP發送或接收1024字節的數據，那麼一般來說我們就必須等待一半的時間（533 ms）才能把交互式應用程序的分組數據發送出去。
解釋：SLIP有個缺陷是數據幀中沒有類型字段。如果一條串行線路用於SLIP，那麼它不能同時使用其他協議。若此交互應用程序先發送數據，那麼它等待的時間是0ms，若是ftp發送數據，那麼它將佔用1066ms的時間，則交互應用程序將要等待1066ms，平均下來即等待533ms
假定我們的交互分組數據可以在其它“大塊”分組數據發送之前被髮送出去。大多數的SLIP實現確實提供這類服務排隊方法，把交互數據放在大塊的數據前面。交互通信一般有Telnet，Rlogin，以及FTP的控制部分（用戶的命令，而不是數據）。這種服務排隊方法是不完善的。它不能影響已經進入下游（如串行驅動程序）隊列的非交互數據。同時，新型的調制解調器具有很大的緩衝區，因此非交互數據可能已經進入該緩衝區了。
對於交互應用來說，等待533 ms是不能接受的。關於人的有關研究表明，交互響應時間超過100-200 ms就被認爲是不好的[Jacobson 1990a]。這是發送一份交互報文出去後，直到接收到響應信息（通常是出現一個回顯字符）爲止的往返時間。
把SLIP的MTU縮短到256就意味着鏈路傳輸一幀最長需要266 ms，它的一半是133 ms（這是我們一般需要等待的時間）。這樣情況會好一些，但仍然不完美。我們選擇它的原因（與64或128相比）是因爲大塊數據提供良好的線路利用率（如大文件傳輸）。假設CSLIP的報文首部是5個字節，數據幀總長爲261個字節，256個字節的數據使線路的利用率爲98.1%，幀頭佔了1.9%，這樣的利用率是很不錯。如果把MTU降到256以下，那麼將降低傳輸大塊數據的最大吞吐量。
在2.9節圖2.5列出的MTU值中，點對點鏈路的MTU是296個字節。假設數據爲256字節，TCP和IP首部佔40個字節。由於MTU是IP向鏈路層查詢的結果，因此該值必須包括通常的TCP和IP首部。這樣就會導致IP如何進行分片的決策。IP對於CSLIP的壓縮情況一無所知。
我們對平均等待時間的計算（傳輸最大數據幀所需時間的一半）只適用於SLIP鏈路（或PPP鏈路）在交互通信和大塊數據傳輸這兩種情況下。當只有交互通信時，如果線路速率是9600 b/s，那麼任何方向上的1字節數據（假設有5個字節的壓縮幀頭）往返一次都大約需要12.5 ms。它比前面提到的100-200 ms足夠小。需要注意的是，由於幀頭從40個字節壓縮到5個字節，使得1字節數據往返時間從85 ms減到12.5 ms。
不幸的是，當使用新型的糾錯和壓縮調制解調器時，這樣的計算就更難了。這些調制解調器所採用的壓縮方法使得在線路上傳輸的字節數大大減少，但糾錯機制又會增加傳輸的時間。不過，這些計算是我們進行合理決策的入口點。