[xiph-rtp] Reliable Inline Codebook Delivery

[David Barrett]

Aaron Colwell wrote:
> David, I'd be interested in your current solution. I think that would
> be a good starting point for developing a standard for this codebook
> delivery standard. Ideally I'd like to turn it into something more
> generic that allows reliablility of some packets in an RTP session.

Well for the moment, I've punting on the whole issue until it settles
down a bit, and I just use a makeshift approach where the broadcaster
transmits the encoding parameters in the SIP invitation, and the 
receiver generates the codebooks from those (I currently control both 
the client and server, and they both use the Theora reference encoder, 
so it's workable... for now).

What I would *like* to do is something like the following:

1) Server (aka, broadcaster) SHOULD state in the SIP/SDP invitation
    which codebooks it intends to use.  (How specifically I don't know,
    but the end result should map "codebook ID"->"codebook hash".)

2) Client SHOULD send "codeback ACK" for each codebook it already has
    (notifying the server it needn't be retransmitted) precisely once.

3) Client SHOULD send "retransmit codebook" for each codebook it
    *doesn't* have (notifying the server it should be transmitted) at an
    exponential backoff rate. (Send at 0s, 1s, 2s, 4s, 8s, etc.)

4) Server SHOULD retransmit the unacknowledged codebooks at an
    exponential backoff rate until it receives a "codebook ACK" message
    from the client.  (Client MUST send "codebook ACK" when received.)

5) The server CAN delay broadcasting with a given codebook until it has
    been acknowledged.  (Note, it needn't wait until all codebooks have
    been delivered, just the one that it wants to use.)

6) The server CAN send new codebooks at any time.  Likewise, if the
    client ever receives a packet encoded for a codebook it doesn't have,
    it SHOULD send a "retransmit codebook" request.  The client CAN queue
    packets encoded in an unknown codebook for later playback, or it CAN
    ignore them.  (This handles the case where pre-specifying codebooks
    is impossible or undesirable.)

7) The client CAN issue "retransmit codebook" requests at any time, and
    a server MUST mark a codebook as unacknowledged when received.  (This
    allows a client to limit the size of its codebook cache by discarding
    in a LRU or whatever fashion.)

Naturally the RTCP messages themselves might be lost, but at worst it 
means the server unnecessarily retransmits a codebook.


I see two big implementation challenges: dealing with fragmented 
codebooks, and crafting the best STP syntax.  Regarding fragmented 
codebooks, I see two options:

- For simplicity, the client could just send one "codebook ACK" for the
   entire codebook when all fragments have been received.

- For efficiency, the client could send one "codebook ACK" for each
   fragment, thereby reducing retransmits.

I'm not passionate either way, though I'd lean toward simplicity. 
Regarding STP syntax, I like what you (Aaron) proposed before.

-david