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

From: Erik Nordmark <[email-masked]>
Date: Tue, 17 Aug 1999 16:07:41 -0700 (PDT)

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?

>    bytes (10 for 2-bit FEC suffix, 11 for 28-byte FEC suffix).  This

s/2-bit/2-byte/ ??

>       +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |               |              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
bytes, so IP payload size can be up to 1480. [this is an issue in
several figures.]

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.

>   transmission errors have been categorized in to three main types: 1)

s/in to/into/

  Erik & Thomas

---

From: Dan Zigmond <[email-masked]>
Date: Mon, 23 Aug 1999 16:42:29 -0700

One line is approximately 9600 baud.  General practice today is to use
anywhere from 1 to 4 lines, with the average probably closer to 1 than to 4.

	Dan

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

-----Original Message-----
From: Erik Nordmark [mailto:[email-masked]]
Sent: Monday, August 23, 1999 4:28 PM
To: Dan Zigmond
Cc: 'Erik Nordmark'; [email-masked]'
Subject: RE: FW: Issues in draft-ietf-ipvbi-nabts-03.txt

> Erik,
> 
> I think your suggestions are very reasonable.  I would suggest 60 seconds
as
> values for both N and M.  How does this sound?

Fine with me.
But I don't what what bandwith the ipvbi channel has so I can't tell
if this will cause significant overhead.

   Erik

> 	Dan
> 
> 
> ---------------------------------------------------
> Dan Zigmond
> Senior Manager, Broadcast Applications
> WebTV Networks, Inc.
> [email-masked]
> ---------------------------------------------------
> 
> 
> -----Original Message-----
> From: Erik Nordmark [mailto:[email-masked]]
> Sent: Monday, August 23, 1999 12:25 PM
> To: Dan Zigmond
> Cc: 'Erik Nordmark'; [email-masked]'
> Subject: RE: FW: Issues in draft-ietf-ipvbi-nabts-03.txt
> 
> 
> > 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.
> 
> 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
> 
>