Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!sdd.hp.com!think.com!mintaka!spdcc!rbraun
From: rbraun@spdcc.COM (Rich Braun)
Newsgroups: comp.dcom.lans
Subject: Re: SLIP/PPP perf. differences
Message-ID: <7611@spdcc.SPDCC.COM>
Date: 22 May 91 20:18:15 GMT
References: <1104@venice.SEDD.TRW.COM>
Organization: Kronos Inc., Waltham, Mass.
Lines: 28

verket@venice.sedd.trw.com (Paul Verket) writes:
>I've read the SLIP and PPP RFCs but I didn't get a feeling for
>performance differences between the two.
>I definitely notice the echo delay ...
>Does PPP reduce packet sizes for interactive applications?

As I understand it, PPP by itself doesn't give you a significant
improvement.  What you want is an implementation of RFC-1144, which
is the header-compression algorithm for SLIP and/or PPP.  (I don't
know if header-compression has been granted a TLA [Three Letter
Acronym] yet.)

Header compression was designed exactly for your situation: reducing
echo delay for interactive sessions.  According to RFC-1144, "One
typed character results in a 41-byte TCP/IP packet being sent and
a 41-byte echo being received.  The line speed must be at least 4000
bps to handle these 82 bytes in 200 ms."

Header compression brings your 41-byte echo packet down to something
like 3 bytes, by eliminating redundant information which appears
repeatedly in packet headers during the course of a connection.  Each
side of the protocol must maintain a table of active connections.

I haven't seen this in operation, but I have specified that PPP with
header compression be used in a new product my company is developing,
so I should be seeing it soon.

-rich