Subject: RE: FW: Issues in draft-ietf-ipvbi-nabts-03.txt

From: Dan Zigmond <[email-masked]>
Date: Fri, 20 Aug 1999 13:23:19 -0700

I believe the text was inserted by me as a late edit while our principal
editor was on vacation, and was a result of a brief misunderstanding on my
part about this issue.  So I believe the intent of the draft, prior to my
edit, was not that the IPVBI CRC should catch these packets.

	Dan

---------------------------------------------------
Dan Zigmond
Senior Manager, Broadcast Applications
WebTV Networks, Inc.
[email-masked]
---------------------------------------------------

-----Original Message-----
From: Erik Nordmark [mailto:[email-masked]]
Sent: Friday, August 20, 1999 1:11 PM
To: Dan Zigmond
Cc: [email-masked]'
Subject: Re: FW: Issues in draft-ietf-ipvbi-nabts-03.txt

Sorry for being slow at responding - I have a few emails to process
after being gone for 6 weeks.

> > > So what is the intent?
>  
> Hmm.  This seems to be a relic of past changes to the spec.  However, such
> an erroneous packet is rebuilt there is a VERY high chance that the UDP
> checksum will fail, and that the IP identification field will be so far
off
> that the client implementation could assume it is an error condition.  

1) The UDP checksum is optional.
2) The IP ID is just a identifying number (used for fragmentation
   and reassembly) and the receiver does not discard packets with "bad" 
   (whatever that might mean) IP IDs.

But you still didn't answer the question about intent?
Was the intent that the IPVBI CRC should catch packets in this case
or not?

> We might want to change the wording in the first paragraph above to read:
> 	"In the event that a sender recycles a group
> 	value but the receiver somehow misses the uncompressed header, the
> UDP
> 	CRC check will likely fail (if used) or the IP identification field
> will be 
> 	incorrect and the receiver may wait for an uncompressed header with
> this 
> 	group value before trying again."

See above for the fundamental issue.
BTW: UDP CRC should presumably be UDP checksum.
 
> Otherwise, we should just remove the wording from the draft completely.

   Erik

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 23 Aug 1999 12:25:19 -0700 (PDT)

> edit, was not that the IPVBI CRC should catch these packets.

So the protocol spec as it stands specifies a protocol where 
1) there are no time limits for how quickly a sender (compressor) can reuse 
   the group value,
2) there is no way for the receiver to detect that the sender has reused
   a group value (if the single uncompressed packet is lost or currupted).

As a result a single lost or corrupted packet will result in garbage
UDP decompressed packets for a possibly unlimited amount of time
(since there is no stated requirement on how often uncompressed packets
must be sent/refreshed by the compressor).
Single UDP checksums are optional in IPv4 this corruption might be undetected.
Even if the UDP checksum is used and it detects the corruption no data is
delivered to the receiver!

This seems pretty broken to me - the protocol should be specified so that
it can handle a single packet loss in a reasonable manner.

Does the working group have a problem with specifying time limits such as
1. A group number can not be reused until after N seconds after the
   last packet was sent using that group number.
2. A compressor should periodically (every M seconds; where M is a number <= N)
   send an uncompressed packet for each active group number.
	Thus implies that the decompressor should discard any state for
	a group number when it has not seen an uncompressed packet for N 
	seconds.

	This avoids any incorrectly decompressed packets due to group
	number reuse, and limits the outage due to a lost uncompressed
	packet to M seconds.
 
   Erik