Re: ATM comparison etc..RE: About some issues (RE: Alcatel Space interest about IP/DVB)

["Kearney" <clausen@cosy.sbg.ac.at>]

----- Original Message -----
From: <harri.hakulinen@nokia.com>
To: <ip-dvb@erg.abdn.ac.uk>
Sent: Monday, April 22, 2002 6:53 AM
Subject: ATM comparison etc..RE: About some issues (RE: Alcatel Space
interest about IP/DVB)


>
> Moro, It seems that I have already been falling behind
>       with my answers ..
>
Hello Harri,

I agree with your comments mostly but for the sake of discussion and
possibly more insight, lets continue the arguments:
> >
> > > Comparison to ATM
> > > It is a matter of taste, if this makes any sence, but if you
> > > do it, I think that it is fair to say that PID is roughly the
> > > same concept as VPI(/VCI) in ATM.
> > >
> > this is a point where I disagree. A  VP/VC   is basically a
> > point to point connection whereas a PID is a broadcast channel.
>
> Lets play that PID is analogous for point-to-multipoint VP/VC,
> that is also defined in ATM. Then, what is the functional
> difference ?
>
> I think that "switching" or multiplexing on TS level really is
> designed to work based on PID's, in the same way than it works
> on ATM based on VP/VC.
>
The ATM VP/VC has a global i.e. network-wide scope and it is bound at
connection set-up using the E.164 or NSAP address which is sued for routing;
its basic purpose is to enable switching. A Mac-level address has a local
scope just on that one link/channel where it is used and it assists in
deciding which interface is the recipient. In the case of the PID - as long
as you do not consider a re-mux as a switch but just as some sort of
repeater, the PID is more like a physical address. As soon as you do
switching based on the PID field you are extending the scope of that
identifier and adding semantics to it.

> You can always do something in different way that it was designed
> to work in the first place, but I am not sure if you should
> (I guess that unrelated, but "a classic" example of that kind of
>  work in "IETF world" would be the consept of NAT's (Network Address
>  Translators). They work, they are usefull in some cases, but overall
>  they tend to introduce lots of new/stupid problems, that were not
>  part of the original concept (end-to-end IP based routing)).
>
Actually, that is what happende to the ATM VP/VC which originally was never
intended to be used for multicasting but just for point - point services;
then multicast functionality was defined into it at a later point in time.

> > > And, what is even more
> > > interesting, mpeg section format is very close to AAL5, or
> > > at least it offers the same functionality (and of course,
> > > MPE builds on mpeg section format..)
> >>
> > AAL5 is a lot "leaner" than the Section structure which is
> > really tailored to the transmission of tables ...
>
> I agree, that AAL5 is "leaner", but the additional fields
> to section structure were added to tailor it for broadcast
> kind of network..
>
> Still I think that they have the same level of functionality.
>

that is the  point - the Section is very specifically tailored to the
reliable and robust transmission of PSI tables and several of the fields in
the Section header suppor this specific application.
What AAL5 is doing and we are trying to do is define a very simple
encapsulation for different payloads and put the specific fields in what
IPv6 calls the "next level" header; this si in principle very similar to
what the adaptation fieds in the TS packet are for - the basic header is
extremely simple - 4 bytes - and if you need more functionality you extend
it with an adaptation header.
>
> > > Multifeed/ "satellite onboard processing" case
> > >
> > > If we recocnise, that PID actually forms "a connection" or "a pipe"
> > > in a same sense than VPI/VCI does in ATM, it means that every
> > > "feed" should use it's own PID to transmit, and every receiver
> > > should receive from those PID's separately (and thus listening
> > > to those feeds that it is interested in).
> > >
> > of course you can consider the TS packet stream conveyed by
> > one PID as a "pipe" i.e. point to point, but in general it is
> > a broadcast  channel. You can multiplex several services on one PID
> > if you introduce a discriminator ("label", "address") on the next
> > level and use this for filtering - actually both, PES and Section
> > packets have such a field called stream_id resp table_id in
> > the MPEG standard.
> >
>
> There is only one table_id (so far?) reserved for MPE.
>
> If you are really "multiplexing" other table_id:s to same PID,
> they need to contain something else than MPE encapsulated data packets.
>
> You can of course introduce a swicth that is working on "MPE level" and
> relies e.g. MPE MAC address on "multiplexing".
>
my point was that the table_ID or stream_ID in teh case of PES packets is a
discriminator field which the receiver might use to decide what to do with
this payload; it is sort of a UU signaling in terms of the ATM/AAL5 people.
But you could as well introduce a "label" field which could assist in
routing/switching. The reals question is - Gorry has addressed this in his
message - that you would either have to reassemble the encapsulated packet,
or - and this makes more sense, project the label into each TS packet as a
sort of extension to the PID. In this case you are really emanating the ATM
VP/VC structure with the PID/Label fields - and you can do this in a point-
point ore -multipoint way.

> > > This also means, that "onboard swicth" in satellite systems should
> > > in fact be a remux, forming an "multiprogram transport stream"
> > > from incoming "singleprogram transport streams", if it is working
> > > in MPEG TS level. (In other words, satellite onboard processor
> > > should not be able "to mix" ts packets coming in with different
> > > inputs by using the same PID.)
> > >
> > what is the difference between a remux and a switch ???
>
> I quess in this context it is used to describe a device that takes
> in n times "complete" Transport Streams and outputs only one. Btw,
> I think that their "swithing" functionality is based on PID's..
>
Coming back to your recent remark on how much overhead we could save with
the new encapsulation: it is interesting to look at the design of the RTP
protocol and some of the rearks in the ROHC area: these people worry about
every bit they transmit - RTP has a clever scheme for signaling Padding
information without actually including it in the packet structure, assuming
that the lower layer protocol(s) know best how to make use of the basic
transmission units.
And as Haral remarked - we might be confronted with a bunch of different
cell sizes (Pardon TS packet) in the future, particularly on the various
return channel systems.

> //Harri
>
-- Horst