Subject: RE: Current LINK snapshot available

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 20 Oct 1999 16:45:06 -0500

Jamshid - most of the IETF workgroups are restricting seats in the first TWO
rows to people who have read the drafts. PILC, however, will be restricting
seats in the FIRST row to people who find the missing "not"s :-o

Welcome to the front row, and thanks for having watchful eyes. (Never a dull
moment!)

Spencer, who is submitting two or three I-Ds this week, and who is probably
also seeding mine with interesting ideas...

> -----Original Message-----
> From:	Jamshid Mahdavi [SMTP:[email-masked]]
> Sent:	Wednesday, October 20, 1999 4:21 PM
> To:	Phil Karn
> Cc:	[email-masked]
> Subject:	Re: Current LINK snapshot available
> 
> 
> Heh...  In http://people.qualcomm.com/karn/pilc.txt:
> 
>   "However, we recommend that subnetworks should attempt to
>    gratuitously re-order segments."
> 
> I think there is a "not" missing!  But it is quite amusing :-)
> 
> --J

---

From: Mikael Degermark <[email-masked]>
Date: Tue, 26 Oct 1999 12:55:37 +0200

The interesting properties of a link over which header compression such
as 1144 or 2507 or 2508 is to be used is that 

1. packets are delivered in the same order as they were sent
2. the length of the payload is made available to the decompressor
2. the loss rate is not too high (especially true for 1144 and 2508).

So if Spencer can guarantee these over his path by 
some means, hc will work.

Cheers, 

Micke

At 09:55 PM 99/10/25 -0500, Spencer Dawkins wrote:
>Steve,
>
>OK, I'll bite. I wouldn't say a null modem cable is a CONNECTIONLESS
>subnetwork - unless the RS-232 cable is LYING to you, it has two ends, and
>all resources along this subnetwork are reserved for the conversation
>between the two hosts, so - what did you mean by a "connection-oriented
>network"?
>
>Stepping back a tiny bit, aren't we trying to describe a path through a
>subnetwork that is relatively stable (think, "call setup request", in
>software), so that the use of delta encoding in RFC-1122 header compression
>makes sense, because most packets are delivered in the order they were sent?
>If so, reserving such a path through the use of dedicated hardware has this
>property in the same way as reserving such a path via resource-reserving
>software (and I didn't actually spell out RSVP on purpose!).
>
>Spencer
>
>> From:	Steve Deering [SMTP:[email-masked]]
>> Sent:	Monday, October 25, 1999 6:08 PM
>> To:	Phil Karn
>> Cc:	[email-masked]; [email-masked];
>> [email-masked]
>> At 10:01 AM -0700 10/22/99, Phil Karn wrote:
>> >I agree that the wording may be unnecessarily restrictive, but it is
>> >true that header compression is usually done over connection-oriented
>> >networks.
>> 
>> 
>> Phil,
>> 
>> A common use of VJ header compression is (or at least was at one time)
>> on an RS-232 serial cable directly connecting two machines (i.e., no
>> modems involved).  That is not a "connection-oriented network", any more
>> than is an Ethernet cable with two nodes attached.
>> 
>> Steve
>> 
>