Subject: Re: [Rmt] Rmt Digest, Vol 66, Issue 8

From: "Luby, Michael" <[email-masked]>
Date: Sat, 30 Jan 2010 14:28:24 -0800

Isn't max source block Length in units of bytes and ESIs iN units of symbols?

----- Original Message -----
From: [email-masked] <[email-masked]>
To: [email-masked] <[email-masked]>
Sent: Sat Jan 30 12:00:02 2010
Subject: Rmt Digest, Vol 66, Issue 8

If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to 

https://www.ietf.org/mailman/listinfo/rmt

Click the 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME.  You can set this option
globally for all the list digests you receive at this point.

Send Rmt mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/rmt
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Rmt digest..."

---

From: Brian Adamson <[email-masked]>
Date: Sat, 30 Jan 2010 19:32:54 -0500

According to the text from RFC 5445 Section 3.2.2.2:

"Maximum-Source-Block-Length: a non-negative integer, less than 2^^32,  
indicating the maximum number of source symbols in a source block"

it's in "symbols"  ...

So the question is whether a 32-bit symbol id was intended or if the  
block length should be 16-bits.  I would _guess_ the latter was the  
intention given this is the _compact_ no FEC scheme?

Brian Adamson
[email-masked]

On Jan 30, 2010, at 5:28 PM, Luby, Michael wrote:

> _______________________________________________
> Rmt mailing list
> [email-masked]

---

From: "Luby, Michael" <[email-masked]>
Date: Sat, 30 Jan 2010 16:45:10 -0800

I see.  However, I'm not sure that this qualifies as an "errata", or is simply a waste of 16 bits in the FEC OTI.  On the other hand, as it is now, the FEC OTI is essentially the same for all the schemes described in this document (the only difference that I saw is that in some there is a "reserved" field whereas in others this reserved field is the FEC Instance ID), so there is the advantage that they are all the same.  Also the overall FEC OTI is not very long to start with and only needs to be received once per object, so the wastage is pretty minimal.  However, I don't have a strong opinion either way so if people feel that this rises to the level of an error that deserves an errata, that is fine with me.

On 1/30/10 4:32 PM, "Adamson@Itd. Mil" <[email-masked]> wrote:

it's in "symbols"  ...

Brian Adamson
[email-masked]