Mikael,
thanks for the reference. That paper is still on my ToRead stack but I
guess I was never so concerned about header compression in the past then I
am now.
Please tell me briefly how the new scheme deals with packet loss on the
link. It can't just use differential encodings, right? Are you maybe doing
some FEC/Interleaving on the headers?
///Reiner
At 11:21 PM 1/21/99 , Mikael Degermark wrote:
>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.
>
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:19 EST