Re: Rmt Digest, Vol 66, Issue 8

The issue that brought this up was a question from a developer who was  
confused by this.  They were unclear as to whether the FEC Payload ID  
picture was in error or the FEC OTI picture was in error.  They were  
thinking they should perhaps use a 32-bit symbol ID.

The other issue with leaving it as it is with a "wasted 16-bits" is  
that the OTI is that it is really a wasted 32-bits since the OTI could  
be specified as 10 bytes total per the following instead of 14 bytes  
as currently depicted. (This retains the one-half 32-bit word that  
allows ALC and NORM EXT_FTI to be 32-bit aligned (i.e. w/ 2 byte  
header extension header).  In principle the wastage is _usually_ not a  
major issue but we have very loosely coordinated multicast  use cases  
where we include the EX_FTI on every packet bearing content.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Transfer Length                          |
       +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                               |     Encoding Symbol Length    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Max. Source Block Length    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Brian Adamson
[email protected]




On Jan 30, 2010, at 7:45 PM, Luby, Michael wrote:

> 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 protected]>  
> wrote:
>
> 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 protected]
>
>
>
>
> On Jan 30, 2010, at 5:28 PM, Luby, Michael wrote:
>
> > Isn't max source block Length in units of bytes and ESIs iN units of
> > symbols?
> >
> >
> > ----- Original Message -----
> > From: [email protected] <[email protected]>
> > To: [email protected] <[email protected]>
> > 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 protected]
> >
> > 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 protected]
> >
> > You can reach the person managing the list at
> >       [email protected]
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of Rmt digest..."
> > _______________________________________________
> > Rmt mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/rmt
> >
>
>
> _______________________________________________
> Rmt mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/rmt

_______________________________________________
Rmt mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rmt