Re: Remarks concerning IP-over-DVB

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

Torsten, you raise some interesting issues, here are my comments!

Are there other viewpoints on where we should be going?

Gorry

Torsten.Jaekel@FTK.rohde-schwarz.com wrote:
> 
> Dear all,
> 
> Actually I watch and usually I read all the emails from this reflector.
> Unfortunately I am so busy or often not in the office.
> Therefore I am not able to answer immediately. I applogize that I am still so
> quite here in this group.
> 
> Therefore I would like "take" the buck to put across some thoughts, remarks and
> questions according to the
> topic of this group.
> 
> 1. In order to make IP-over-DVB more efficient I still believe that the approach
> "MPLS" could work:
>      Imagine we transmit each IP connection in a dedicated DVB sub-channel,
> given by the PID, we could
>      drop the IP headers. We have an unambiguous mappimng between IP and PID.
> The PID acts as our
>      label. On the receiving side (the engress of our "DVB-MPLS cloud") we
> recreate the IP header.
>      Think, saves a lot of recources (the complete header).
>      Works just in case single IP in a dedicated PID. Often we transmitt many IP
> connections in one PID (or all
>      in a single PID). Here we could compress headers but not remove. We still
> need the IP addresses as
>      sub-labels inside PID-channels.

This seems to be relevant, it talks of a way to improve bandwidth
efficiency, however
I'd probably say this was "compression".  MPLS adds extra tags to
simplify routing,
whereas the proposed work in the IETF ROHC WG replaces the IP (and
sometimes other 
headers UDP, RTP,  TCP?) with small header and a context id.

> 
> 2. In order to have routing function (we are working on our MediaRouter) we need
> this mapping between IP
>     and PIDs. Problem here, you have to use a free PID and create a new one (if
> you insert behind a
>     multiplexer). Perhaps it is necessary to read the SI tables to know which
> PID is in use and which could be
>     use (to modify the tables to signal where is the data stream/IP is not a big
> deal).
>     When the tables are connected with the routing engine it is guaranteed that
> you can change the PID for
>     your TV program (new PID) and this is not disturb by the inserted data.
>     But: how flexible could be this ? Could you change and use a new PID
> on-the-fly ? Does the receiver is
>     able to find the new PID to have an uninterrupted data flow ?
> 

OK, so this also relates to the discussion on "arp" type mechanisms

> 3. Next problem: Everything in such a MPEG network is fixed, means the PIDs are
> setup permantently.
>     And just the system designer knows exactly which bandwidth is used by which
> PID for which service.
>     How we could define an interface to have access to such a DVB/MPEG network ?
> Means: how I can
>     allocate a channel, with bandwidth for a limited time period (similar to
> Call Setup and Release in telephone
>     networks or Resource Reservation Protocols). As far as I know there is no
> approach fopr such functions.
>     In DAB systems (Digital Sound Broadcasting) we have the STI interface which
> support such functions in
>     a very flexible way. The service provider can manage his assigned resoruces,
> remotely and automated..
> 
> 4. Question: Should all this work here (a more efficient IP-over-MPEG) consider
> to have a mixed TV and data
>     system ? Means: We have to share the "wires" with ongoing running TV
> programs ? Or is the approach
>     to use an entire transport stream just for data (pure data transmission) ?
>     Next question: How important is interoperability, with exiting receivers and
> decoders and with transport stream
>     devices ? Imagine that there is a MPEG-2 infrastructure using MPEG-2 routers
> operating on SI tables, PIDs
>     etc. Has this still be working ?
> 
> 5. One remark was to use an ATM-like approach. Why not (know a bit ATM), and I
> think the satellite guys are doing
>      this already. But MPLS is also based on ATM, therefore again MPLS. Instead
> of the ATM header (not so complex
>      as IP but still needed to be scanned and parsed) we can use again the PID
> as label.
>      But an approach like: IP-over-ATM, ATM-over-MPEG is not efficient. ATM does
> not support service reliability without
>      higher layers (error handling, flow control). The quality of service aspect
> (QoS) which we know from ATM comes from
>      the very small cells. In MPEG-2 we have larger "cells", the 188 byte
> packets. To put ATM on it does not make the
>      "cells" smaller.
>      To support different service especially CBR (constand bit rate, for
> streaming media), VBR (for real-time service)
>       and ABR (available bit rate for email, file transfer) is needed. But flow
> control for CBR works just with very small cells.
>       Problem: how to perform traffic shaping with "MPEG-cells" (the 188 byte
> blocks) ? If we add latency and jitter we
>       influence dramatically the running TV programs. Works just in a pure data
> environment (no PCRs, Program Clock
>       References used and needed inside MPEG-2 streams) but not so efficient
> like ATM due to the larger units.
> 
> 6. If we want make IP-via-MPEG more efficient it does not makes sense to drop
> just the DSM-CC overhead. We save a
>     few bytes but another large wasted bandwidth is within the SI tables. Short
> tables are filled with stuffing due to the 188 byte
>     borders. Here we could increase the available bandwidth, too. And, the
> processing of the complex tables could also
>     be canceled.
>     Is this the intention ? If yes, what does it mean: IP-over-What ? I belive
> just over 188 byte cells (just the sync word 0x47 is
>     still used). But than ATM over a coax link is even more efficient and
> protocols are existing for the applications and services.
> 

Interesting - should we do away with SI tables reflecting IP content?
Or is the Si to valuable for compatibility reasons?
Is there some compromise - IP signalling with SI to identify PIDs to
other equipment?

> 7. Unicast and Multicast:
>     Is there a problem: The difference is just the type of IP address and
> perhaps some IP header information. The MPEG-2 transport
>     stream network itself is not a multicast network, or is it ? Means: is there
> an device to duplicate streams in order to send it as
>     identical copies to different locations ? If wou want do this you have to
> use remultiplexers. But if you bear in mind to design
>     your IP-to-PID mapping well, it should work to route transport streams. But
> the same problem. Perhaps you have to know
>     the PID allocation and useage, the routes in such a MPEG network to decide
> in which PID hI have to put my multicast IP in
>     order to have many outgoing data connections.
> 

Yes, but the multicast service in IP needs receivers to have the ability to
identify which PIDs they need to listen to, based on the IP join (IGMP group
membership, or routing protocol - which only tells them the IP group
address and 
IP source address, and not the "MAC address" or in MPEG case "PID"
number on 
which it is carried. But surely in DVB - it may even be on a different
multiplex? 
How do we find where the IP multicast traffic is being sent?

It would even be possible to envisage a system in which the IP traffic was
only sent if there wer valid downstream receivers wishing to receive the 
particular flow. How should this be managed over a DVB system?

> My summary: an exciting and interesting topic but what is the target ? Just to
> save a few bytes to increase the bandwidth for
> IP ? Not enough. We have to think in services, applications. 100 Kbit/s more
> throughput is not a "unique selling proposition"
> because with a better service compression (Internet-MPEG-4-movies, MP3 vs. AAC,
> HTML text compression) I could have
> the same effect. More important, which type of connections or type of traffic
> profiles we have to support and how we could manage
> this. This seems to me as complex as the ATM challenge was and is (traffic
> engineering and management).
> I see a lot of opportunities, interesting and challanging items but does this
> effort is valuable ? Is a MPEG infrastructure the common
> basis of IP networking in future ? I do not think so. IP via MPEG remains the
> extension and supplement of digital TV or isn' it ?
> 

Well, DVB components are being used in many current and next generation systems
which do not carry any TV. They are purely IP services. Why DVB? -
Because it
allows the system to be upgraded / re-used in the future for TV? - Or just
because the technology has reached the mass market place? All "radio" 
systems need components - common designs are much cheaper...

> Sorry for my brains emission but I have wanted to chip in some ideas and
> thoughts. Do not hesitate to reflect to my "none-sense".
> 
> Best regards.
> 
> Torsten
> 
> Torsten Jaekel
> Product Marketing Datacasting
> Rohde & Schwarz FTK GmbH
> Wendenschlossstr. 168, Haus 28
> 12557 Berlin
> Germany
> Phone: +49 30 65 89 1 - 103
> FAX:     +49 30 65 55 02 21
> email: Torsten.Jaekel@FTK.rohde-schwarz.com
> 
> PS: Please, I apologize my English mistakes, not my native language and written
> quite in hurry.