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

From: Brian Adamson <[email-masked]>
Date: Mon, 1 Feb 2010 10:28:39 -0500

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-masked]

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-masked]>  
> 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-masked]
>
>
>
>
> 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-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..."
> > _______________________________________________
> > Rmt mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/rmt
> >
>
>
> _______________________________________________
> Rmt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rmt

---

From: "Watson, Mark" <[email-masked]>
Date: Mon, 1 Feb 2010 09:23:04 -0800

This is not an error. It is this way for backwards compatibility with the Experimental RFCs.

The binary format of the FEC Object Transmission Information was originally defined in the FLUTE RFC (for use in the EXT_FTI LCT Header Extension). Section 5.1.2.1 of RFC3926 defined the FEC Encoding Id-specific portion of the FEC OTI for FEC Encoding Ids 0, 128 and 130 (The "Compact" FEC Schemes) and defined the Maximum Source Block Length to be 32 bits. At least FEC Encoding Id 128 has a 32-bit Encoding Symbol Id.

Now, we could decide to abandon backwards-compatibility in favour of efficiency, but this would not be an errata. Also I think the Compact No-Code FEC Scheme has likely been implemented fairly widely according to the existing specifications and so we would be in danger of making some existing implementations non-compliant (or, more accurately, of breaking alignment between IETF and other specifications).

...Mark

On 2/1/10 7:28 AM, "Brian Adamson" <[email-masked]> wrote:

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

Brian Adamson
[email-masked]

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]

---

From: Vincent Roca <[email-masked]>
Date: Wed, 03 Feb 2010 15:00:46 +0100

Hi,

I agree with Mark. No matter the reasons that led to the current EXT_FTI 
format
(and backward compatibility is anyway a good reason), do not change 
anything.
Then if we think this 32 bits waste per packet containing this EXT_FTI 
is really
an issue, we can as well specify another FEC Encoding ID to fixe it. It 
is IMHO
a wiser solution.

Cheers,

    Vincent

On 02/01/2010 06:23 PM, Watson, Mark wrote:
> The binary format of the FEC Object Transmission Information was 
> originally defined in the FLUTE RFC (for use in the EXT_FTI LCT Header 
> Extension). Section 5.1.2.1 of RFC3926 defined the FEC Encoding 
> Id-specific portion of the FEC OTI for FEC Encoding Ids 0, 128 and 130 
> (The "Compact" FEC Schemes) and defined the Maximum Source Block 
> Length to be 32 bits. At least FEC Encoding Id 128 has a 32-bit 
> Encoding Symbol Id.
>
> Now, we could decide to abandon backwards-compatibility in favour of 
> efficiency, but this would not be an errata. Also I think the Compact 
> No-Code FEC Scheme has likely been implemented fairly widely according 
> to the existing specifications and so we would be in danger of making 
> some existing implementations non-compliant (or, more accurately, of 
> breaking alignment between IETF and other specifications).
>
> ...Mark
>
>
>     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
>           |                      Transfer Length
>                              |
>         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.
>
>