Re: Rmt Digest, Vol 66, Issue 8
Vincent Roca <[email protected]> Wed, 03 Feb 2010 15:00:46 +0100
| Newsgroups | gmane.ietf.rmt |
|---|---|
| Message-ID | <[email protected]> |
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:
> 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 protected]> 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
> 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
>
_______________________________________________
Rmt mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rmt