Subject: Re: Choices for TRACK/NACK report encoding

From: Dah Ming Chiu - Sun Microsystems <[email-masked]>
Date: Fri, 8 Sep 2000 16:17:09 -0400 (EDT)

Brian Whetthen wrote:
>My original concern were that I would like us to come up with ONE form for
>NACK encoding, that is the same for both TRACK and NACK, and is as simple
>as possible.  Also, I would like the mechanism to have enough redundancy
>built in that reliable NACKs are not needed.

Yes, this is a very good goal.

I am having a little trouble following Brian Adamson's "hierarchical coding
block" proposal.  I think the problem is with terminology.  If you can
bear with me and explain your needs in simple terms, perhaps we can work
out some common format.

Let me state what I understand, and you can correct me where I err:

In TRACK terminology, regular FEC encoded stream does not require
loss feedback - it is "open loop".  In "reactive" FEC usage, the sender
computes "parity" packets but does not send them until losses are reported.
This is the case error reporting is needed.  What is needed at the sender
to determine what parity packets to send is a count of lost packets (given
a window of packets), rather than the specific packets lost.  This count
determines the number of parity packets needed.

To aggregate the count up the tree to the sender, you need a bitmap to
know which packets are lost by each receiver so you don't count duplicate
packets.  This makes the requirement for reporting losses roughly the
same wether it is ACK, NACK or reactive FEC.

I think the common format can be as simple as
  <seqnum, bitmask>
plus other flags and identifiers.

If we really have a huge bitmask, the question is whether it should sent as
  <track-header><seqnum, bitmask><seqnum, bitmask>...<seqnum, bitmask>
or
  <track-header><seqnum, bitmask>
  <track-header><seqnum, bitmask>
i.e. separate packets.

Could you explain your proposal in this simple terminology?

Thanks
Dah Ming