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

From: Dan Zigmond <[email-masked]>
Date: Tue, 17 Aug 1999 18:03:55 -0700

Erik,

Thanks for catching these.  It looks like you've found a few mistakes.  Here
is what our original editor had to say about how to fix it.

	Dan

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

>  -----Original Message-----
> From: 	Ruston Panabaker  
> Sent:	Tuesday, August 17, 1999 5:51 PM
> To:	Dan Zigmond
> Subject:	RE: Issues in draft-ietf-ipvbi-nabts-03.txt
> 
> >  -----Original Message-----
> > From: 	Erik Nordmark [mailto:[email-masked]] 
> > Sent:	Tuesday, August 17, 1999 4:08 PM
> > To:	Dan Zigmond
> > Cc:	[email-masked]; [email-masked]; 
> > [email-masked]
> > Subject:	Issues in draft-ietf-ipvbi-nabts-03.txt
> > 
> > 
> > In one place the document says:
> >    In the event that a sender recycles a group
> >    value but the receiver somehow misses the uncompressed header, the
> >    CRC check will fail and the receiver may wait for an uncompressed
> >    header with this group value before trying again.
> > 
> > This can only work if the CRC is computed by the sender before the 
> > compression. But further down the document says:
> > 
> >    A 32-bit CRC has also been added to the end of every packet in this
> >    scheme to ensure data integrity.  It is performed over the entire
> >    packet including schema byte, compression key, and either 
> > compressed
> >    or uncompressed headers.
> > 
> > I assume this is supposed to say that for a compressed packet 
> > the CRC is over the compressed content (the use of "either" 
> > isn't very clear).
> > With this assumption the CRC can not be used to detect when a 
> > group value has
> > been reused and the receiver never saw the uncompressed header.
> > 
> > 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.  

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."

Otherwise, we should just remove the wording from the draft completely.
 
> > >    bytes (10 for 2-bit FEC suffix, 11 for 28-byte FEC suffix).  This
> > 
> > s/2-bit/2-byte/ ??
 
That should read "(10 for 2-byte FEC suffix, 11 for 28-byte FEC suffix)"
 
> 
> > 
> > >       +               
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >       |               |              payload  (<1472 bytes) 
> >           |
> > >       +-+-+-+-+-+-+-+-+                                     
> >           +
> > >       |                                                     
> >           |
> > 
> > where does the number 1472 come from? Seems like it should be 1480 or
> > less (i.e., the MTU of the link is 1500, minimal IP header is 20
> > 		
> > several figures.] 

The payload can only be 1472 because an IP packet can be sent with full
headers (20 bytes of IP  header and 8 bytes of UDP header).

> > Merge the two sets of references into one.
> > 
> > A reference to RFC 2119 is missing - it defines MUST/SHOULD etc.
> > The standard boilerplate for this is contained in RFC 2119.

Yes this should be added.
 
> > >   transmission errors have been categorized in 
> > to three main types: 1)
> > 
> > s/in to/into/

Yes (into)
 
> >   Erik & Thomas

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 20 Aug 1999 13:11:14 -0700 (PDT)

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

> 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?

> 	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