verket@venice.SEDD.TRW.COM (Paul Verket) (05/22/91)
I've read the SLIP and PPP RFCs but I didn't get a feeling for performance differences between the two. A lot of my work is done over character mode telnet or remote shell on a 9600 baud SLIP line. I definitely notice the echo delay as I type because of the packeting of each character. Does PPP reduce packet sizes for interactive applications? If so, how does it compare to compressed SLIP? Thanks... Paul Verket
rbraun@spdcc.COM (Rich Braun) (05/23/91)
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
mra@searchtech.com (Michael Almond) (05/23/91)
In article <7611@spdcc.SPDCC.COM> rbraun@spdcc.COM (Rich Braun) writes: >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. Why doesn't regular TCP/IP use this? -- Michael R. Almond (Georgia Tech Alumnus) mra@srchtec.uucp (registered) search technology, inc. mra@searchtech.com 4725 peachtree corners cir., suite 200 uupsi!srchtec!mra norcross, georgia 30092 (404) 441-1457 (office)
rbraun@spdcc.COM (Rich Braun) (05/24/91)
I wrote: >>Header compression brings your 41-byte echo packet down to something >>like 3 bytes ... mra@searchtech.com (Michael Almond) writes: >Why doesn't regular TCP/IP use this? Because Ethernet packets not only have a maximum size (1536 bytes), but they also have a minimum size (64 bytes, I think). The reason for this is to ensure that the collision-detection logic has enough time during a packet transmission to work throughout an Ethernet segment, which has a maximum physical length related to the speed of light divided by the transmission time of said minimum-size packet. (This is a very simplified explanation.) If you look at a typical Ethernet datagram which is shorter than the minimum, you will find it padded out to the minimum length (with zeros, typically). Because of this, there was no incentive to implement header compression on Ethernet implementations. Serial protocols are obviously another matter entirely. -rich
brian@telebit.com (Brian Lloyd) (05/24/91)
mra@searchtech.com (Michael Almond) writes: >In article <7611@spdcc.SPDCC.COM> rbraun@spdcc.COM (Rich Braun) writes: >>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. >Why doesn't regular TCP/IP use this? It costs cpu cycles to do the compresssion and at higher data rates it does not buy you much in the way of performance (remember that you can only type so fast so you are limited to the amount of data that a human can generate). -- Brian Lloyd, WB6RQN Telebit Corporation Network Systems Architect 1315 Chesapeake Terrace brian@napa.telebit.com Sunnyvale, CA 94089-1100 voice (408) 745-3103 FAX (408) 734-3333