Re: [Cellar] Benjamin Kaduk's Discuss on draft-ietf-cellar-ebml-15: (with DISCUSS and COMMENT)

[Michael Richardson <[e-mail]>]

Steve Lhomme <[e-mail]> wrote:
    >>>> Identically Recurring Elements SHOULD include a CRC-32 Element as a
    >>>> Child Element; this is especially recommended when EBML is used for
    >>>> long-term storage or transmission.  If a Parent Element contains
    >>>> more

    >>>> I'm not sure if the "long-term" is intended to also bind as
    >>>> "long-term transmission" (though I'm not sure what it would mean in
    >>>> that case).  It's also not entirely clear what kinds of transmission
    >>>> would benefit from this, as reliable media presumably don't need
    >>>> redundancy for reliability, but unreliable media can't really be
    >>>> used to carry EBML without some framing requirements to know when
    >>>> elements start.

    >>> Actually, as long as you have the "packets" in the right order you
    >>> can use the EBML stream. You can also use it if you're missing some
    >>> packets. The Checksum can help determine if the data are valid or
    >>> not, even if the underlying transport loses some bits. It could
    >>> technically be used as-is as protocol on top of IP, like TCP or UDP.
    >> 
    >> Huh, interesting.  Though I thought that UDP (and IP itself) didn't
    >> guarantee in-order delivery.

    > UDP and IP have no notion or order. But you can create protocols on top
    > that do. Basically an EBML-based streaming format would just be:
    > [Packet Number][EBML element] With EBML element smaller than 4000 or
    > 1512 octets to fit nicely in Ethernet.  Anyway, that's definitely out
    > of the scope of this document ;)

Yes.  I read it as binding more to long-term storage than transmission.

But, not every transmission system is TCP, and EBML would certainly be appropriate
format for video transmissions from a multi-decade long flight of an
interstellar space-craft, and those don't do retransmissions :-)
This is an 'archival' format afterall, so it such a transmission would need
to survive multiple generations of base-station systems.

    > As for the CRC I think it's similar. It depends on what the CRC covers
    > and the decision should probably be done at the semantic level, even
    > with various options on how to handle the data.


-- 
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [