Re: demo stream, filter questions

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

This seems very helpful in clarifying why MPE is designed the way it
is, and the role that MPE is expected to play in the future - particularly
how it matches DVB Multiplex operational needs for TV.

I think we  **should** update section 5 of the requirements draft text, based
on this discussion.

http://www.erg.abdn.ac.uk/users/gorry/ip-dvb/ids/draft-fair-ipdvb-req-01.txt

I could write this based on your mail, but would you be willing to
supply 2-3 text 
paragraphs to add/replace those on MPE? 



Please do see in-line questions.



Gorry

Alexander Adolf wrote:
> 
> Dear Gorry, dear Colleagues,
> 
> On 2002-09-03T10:40+0100, Dr G Fairhurst wrote:
> 
> > [...]
> > > What comes in mind here is that the MPE header is used as hardware
> > > filtering at "MAC/Section" level also. DVB streams are normally high
> > > speed streams (in the future > 100 mbps packet throughput (QAM,
> > > 8PSK)).
> 
> Today 100 Mbps are reality on satellite systems. Looking into the
> future I would expect the satellite operators to add some multiples to
> that. One day we will probably run into physical restrictions imposed
> by the earth's atmosphere. However I am not an expert on this so
> please don't ask me how far we will get... ;-) And then there is still
> otical fibre where you get several Gbps today.

Yes, true TV mutiplexes are often high rate, and in the future data ones
may also be. There are still many data services that use lower-rate multiplexes
(much less than a full transponder/repeater).

> 
> > So... There are several questions here.
> >
> > 1) How significant a feature is "section filtering". I would
> > be interested to know how important this feature is. As I see it,
> > it gives the encapsulator the possibility of forming seperate
> > logical subnetworks within the same MPEG-2 TS Logical Channel.
> > Is this just feature-overload? Is there a good reason for not
> > using a separate PID for each subnetwork?
> 
> Taking into account the transmission link speeds I just mentioned, a
> good amount of the filtering definitely has to be done in hardware.

I agree, hardware assist is good for high data rates (and high packet
rates).  MPE and the lightweight encapsulation could both use 
hardware filters in future.

> 
> But apart from that, 'just' using another PID in a DVB network is not
> as easy as it might seem.
> 
> As DVB networks are television broadcast networks (if not by nature
> then by descent), they are subject to regulatory administration in
> many parts of the world. So you might simply not be allowed to
> introduce a new PID since you haven't registered it with your
> regulator. Of course you can always register a new one, but that takes
> away any dynamicity (which we probably will want).
> 
> Another constraint are the commercial arrangements and business models
> of network operators and service providers (duh, I managed to say the
> nasty 'C' and 'B' words in one sentence!). Often a (e.g. IP) service
> provider rents a specific bandwidth on a specific PID from a network
> operator. This approach could be favorable to both of them since it
> will then be easier to multiplex in the (e.g. IP) service and provide
> easier network planning for the operator. Additionally a malfunction
> of the 'bought-in' service will be much less likely to affect other
> services.
> 
> Some service providers have the model that they feed their service to
> as many (DVB) distribution networks as possible. In the above
> mentioned scenario (renting a specific PID), their service need not
> be taylored to the specific distribution network and they are
> (almost) the sole responsible for the functioning or malfunctioning of
> their service, as blunt PID remultiplexing today is as common and
> reliable as - say - sliced bread.
> 
> As you can see there are many implications, boundary conditions and
> limitations due to the fact that DVB networks are being operated as
> television distribution networks and not as generic interconnection
> networks. The section filtering invented by MPEG and adopted by DVB is
> especially well suited for these (TV) broadcast medium environments
> where remultiplexing comes into play.
> 

OK, so this is a good reason in TV networks why section-handling
is useful. Is this really also the case in data networks?

> > 2) MAC address filtering - we NEED this to run routing protocols,
> > do we need it for directly connected end hosts? If hardware
> > filtering is indeed required, could it not use the IPv4 / IPv6 header?
> > Is this good / bad?
> >
> > > I cannot imagine, that a standard receiver filters at IP or
> > > similar levels in software. MPE has the MAC address field, which tells
> > > the local hardware to set a section level filter. The "minimal header
> > > has no such capability. Will receivers get all packets on that PID ?
> >
> > Yes, currently they would.
> >
> > > How do you build groups of receiver devices ?
> >
> > Use another PID?
> > [...]
> 
> No (for the above mentioned reasons). That is - amongst others - why
> DVB crafted a solution to convey information about IP addresses being
> targetted by specific streams or services. I am currently working on
> getting clearance for forwarding the latest draft of this to you.
> 

OK, but if you choose to use section filters, there may also be drawbacks?

1) MPE has more header fields and options - therefore harder to process,
more complex software / additional silicon.

2) More complex address resolution (another thing to signal)

3) Multicast handling isn't clear to me. 

If I am an ISP wanting to offer unicast, I can use section headers to 
separate the clients into manageable groups (private networks).  

If I wish to add multicast support to my clients, what should I do?

I may not want to send each multicast packet once per "section address",
that would be wasteful replication of packets with the same content.

So, do I form another section address for all multicast groups? 
-  that doesn't seem to provide any section level filtering, we need
to look to MAC source/destination addresses or IP addresses to filter.
I don't yet see the added beenfit in processing the section header.

Another posibility, do I send one section address per multicast group,
then I can do section  filtering - but I need to resolve the IP address
to 
a section address. This seems teh smae function as MAC
source/destination 
addresses. So there's no added benefit here either?

Have I missed something? Can someone help me understand this?


> Best regards,
> 
>   --alexander adolf
>     Chairman DVB GBS
> 
> --
> +++ ATTENTION +++ new location as of 2002-06-10 +++++++++++++++++++++
> +++ new address: Frankenthalerstrasse 2, D-81539 Muenchen, Germany ++
> +++ new phone: +49 89 54845 7203 +++ new fax: +49 89 54845 7900 +++++
> 
> Alexander Adolf, Dipl.-Ing.(FH) --------------------------------------
> Concept Engineer -----------------------------------------------------
> System Software ------------------------------------ info@micronas.com
> Micronas Gmbh - Munich Office ----------------------- www.micronas.com