Re: clausen-ipdvb-enc : Some questions

[Gorry Fairhurst <gorry@erg.abdn.ac.uk>]

Thank you for your questions, we need to debate all the issues in the next
few months so we can make sure we've got the right design.  It's fine to ask
any questions at this moment.

I'll handle a few of these, and expect Bernhard will follow-up with some
more details and the rest of the answers.

On 15/7/03 5:34 pm, "alain.ritoux@6wind.com" <alain.ritoux@6wind.com> wrote:

> Hi all,
> 
> I have some question about the draft "Simple Encapsulation for
> transport of IP over MPEG-2/DVB networks" (draft-clausen-ipdvb-enc-01.txt)
> As a newbie in satellite stuff, some of these questions/precisions
> may be irrelevant, thanks for indulgence ;-)
> 
> 
> 1) SNDU format
> Type field : 2 bytes.
> Tha's sure, getting the ether_type is coll way of next header
> value, and can be esaily kept for other protocols, but do we really
> need 64K possible protocols to be transported over DVB.

OK. We *could* use an alternate type field, we need to do a detailed
analysis of the pros and cons of this. Saving space is a Pro argument.

> May be it can be reduce to a single byte, wich would let a free
> byte (because of alignement), but I'm rather sure, people would think
> of plenty possible usage of those free bits ;-)

The "Simple" encapsulation uses the Adaptation Field and stuffing for
alignemnet, this actually break 32-bit alignment.

If you were to consider "ULE", the Byte alignment wouldn't be helped, except
in the case of the first SNDU in a new TS Packet using ULE, because other
SNDUs are of variable size, and the packing would loose alignment on
subsequent frames.

> 2) Usage of PUSI/AFC
> I don't really get the usage of the AFC. where does the pointer points
> in the two cases ? I think I see, but tell me if I'm wrong :
> 
> 1st case
>                                     +-------------------+
>                                     |Encap | Subnetwork |
>                                     |Header|  PU        |
>                                     +-------------------+
>                                      \                 /
>                                       \               /
>                                        \             /
>         +------*--------*--------------+------------+
>         |MPEG-2| Adapt. |   Stuffing   |     SNDU   |
>         |Header| Header |     bytes    |            |
>         +------+--------+--------------+^-----------+
>                        |                |
>                        +----------------+
> 
> 2nd case
>           +------------------+       +------------------+
>           |   Subnetwork     |       |   Subnetwork     |
>           |      DU 1        |       |      DU 2        |
>           +------------------+       +------------------+
>                      \        \     /          /
>                       \        \   /          /
>                        \        \ /          /
>         +------*--------*--------+----------+
>         |MPEG-2| Adapt. | end of | start of |
>         |Header| Header | SNDU 1 | SNDU 2   |
>         +------+--------+--------+^---------+
>                        |          |
>                        +----------+
> and in the 2nd case, is it possible to stuff bytes between end-SNDU1
> and SNDU2 (for alignement purpose) ?
> 
> In a more general way, wouldn't it be simpler (and cost less in
> overhead) to avoid any AFC header, and to impose SNDU start on 32-bits
> boundaries, because as SNDU will include length indicator, the padding
> will be automatically detected at the receiver side. Surely I miss
> something, and I feel it is around p14, but I don't see where this
> value 0x47 come from  ?
> 

If you avoid the Adaptation Field header, we would create ULE - the key
differences between the approaches is the use of "section-style" MPEG-2
framing (PUSI+Payload_start_pointer) or PES-style MPEG-2 framing (PUSI+AF
with stuffing as needed).

> 3) Fluhsing the bit-stream
> Indeed, the  fact that the encapsulator doesn't wait for another SNDU
> to come to pack, is enough to avoid latency. OK, it resolves the pending
> of an IP packet at the encaspultor level when no other IP packet comes.
> 
> BUT what must be done at TS-muliplex level ? This should be specified by
> the encpaulsation method : if the push packet is not added, what is to
> be done ?
> 

I'd like transport multiplexor manufacturers to tell us what they can do!!!!

All contributions or enhancements of the problem statement would be most
welcome!!

> Thanks again for having read so far ...
> Regards.
> Alain.

Hope that helps a little.

Gorry