RE: PILC: prioritization

Mikael Degermark <micke@cdt.luth.se> Fri, 22 January 1999 07:21 UTC

X-Authentication-Warning: assateague-fi.lerc.nasa.gov: listserv set sender to owner-pilc@lerc.nasa.gov using -f
Message-Id: <3.0.6.32.19990122082148.008846b0@basil.cdt.luth.se>
X-Sender: micke@basil.cdt.luth.se
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
Date: Fri, 22 Jan 1999 08:21:48 +0100
To: Reiner Ludwig <rludwig@CS.Berkeley.EDU>
From: Mikael Degermark <micke@cdt.luth.se>
Subject: RE: PILC: prioritization
Cc: Phil Karn <karn@qualcomm.com>, border@hns.com, mallman@lerc.nasa.gov, pilc@lerc.nasa.gov, vern@ee.lbl.gov, adfalk@mail.hac.com, sdawkins@nortelnetworks.com, rludwig@CS.Berkeley.EDU
In-Reply-To: <199901212059.MAA21182@hofmann.CS.Berkeley.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-pilc@lerc.nasa.gov
Precedence: bulk
Status: RO
Content-Length: 1174
Lines: 28

Reiner,

Take a look at the IP header compression now being standardized 
in the IETF. That will perform much better than VJ header compression 
on the type of link you describe. It also deals better with Timestamp Options,
DiffServ use of the TOS/Traffic Class field, Explicit Congestion Notification
as is now being proposed by Sally Floyd et al. 

draft-degermark-ipv6-hc-08.txt

(don't let the draft name fool you, it covers IPv4 as well.)

It is now being moved to Proposed Standard and should be published as 
an RFC as soon as the RFC Editor has looked it over. There was a paper in 
MobiCom '96 that cover this compression scheme to some extent.

Cheers,

Micke

At 13:00 1999-01-21 -0800, Reiner Ludwig wrote:
>2. Semi-reliable ARQ as you proposed can do a lot of harm when you are
>running VJ TCP/IP header compression which you certainly want to do on a
>low bandwidth link. The reason is that the header decompressor screws up
>when one or more packets are lost causing checksum errors at the TCP
>receiver and thus a loss of an entire window. This is particularly painful
>when you are running over a massively overbuffered link because the windows
>grow huge.