Re: fair-ipdvb-req : Some questions

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

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

> Hi all,
> 
> I have some question about the draft '"Requirements for IP
> transport over MPEG-2 networks" (draft-fair-ipdvb-req-03.txt)
> As a newbie in satellite stuff, some of these questions/precisions
> may be irrelevant, thanks for indulgence ;-)
> 
> 
> 1) some reference don't exist  [DVB-RC] [LINK-ID] [DVB-SIDAT],
> and maybe some other. As a newbie in that stuff, finding its way
> among multiple ISO/ETSI/whatever norms isn't really obvious :-(
> 
Thanks - you're quite right, they'll be in the next rev.

[LINK] 
http://www.ietf.org/internet-drafts/draft-ietf-pilc-link-design-13.txt

> 
> 2) About the TS-multiplex selection
>  2-a related to figure 2
> Maybe I didn't get the point but hiw does it work : is it for
> the sender, a selection between multiple DVB-Sending cards ?
> If so, but managing  one  (or many ?) logical IP interface per
> sending card, I don't see why the 'normal' IP routing souldn't
> be enough.

I don't understand the question.

>  2-b related to figure 3
> The IP encapsulator has no mean to interact with the second TS
> multiplexor, so what is the point ?
> 
The second TS multiplexor simply multiplexes the TS Packets from a set of TS
at the input from one or more places, to produce another TS Multiplex.  In
reality, for a TV service this also involves a lot of other sub-actions,
such as building the correct control information (tables) and inserting
information at the correct time into the TS.

> 3) Packet flows
>  3-a the flow itself
> They are associated with IP source and destination addresses.
> Well is it enough ? I mean, the recent flow-label discussion in
> the IPv6-WG ended up with a flow definition with SRC+DST+Flow_Label
> (http://www.ietf.org/internet-drafts/draft-ietf-ipv6-flow-label-07.txt)
>  3-b the usage ?
> Indeed, why impase taht a single flow MUST use a single PID,
> I would consider it safer, but what is the rational behind it ?
> 
What do you propose?

> 4) Motivation
> In the needed fcts (§3 p10), there is the IPv4 broadcast packet support
> : is there a real need for this ? what is the use-case foreseen ?
> 

"Use cases" should be developed, Jun, sent something about this, and it is
good to collect as many different use cases as we can. (This has been
repeated in many places over the last few days).

> 5) Framework position
> The framework operates below the IP level. Couldn't it be a good
> place to define a logical-interface level (just for exemple, one
> pseudo-interface associated to a group of PID), and to see how to
> defien this group PID properties, in such a way that classical IP
> mechanisms will work 'perfectly' over this interface. By IP mechanisms
> I include not, only the stacks tmeselves, but also routing, ...
> To make myself more clear, ythe level of abstraction could be
> equivalment as the one we find in UDLR.
> Or is it over-specifying, and considered as implementation-dependant ?

I'm keen to focus on subnetwork issues first so we can get the basic
encapsulation protocol out of the way, or at least into a stable draft. We
will need to look at this when we do the address resolution.

> 6) About lenght indicator.
> It is said (§6.3 note ii p17) that when more than 2 payload are present
> in a single TS-cell, the PUSI pointer is only used for the first start.
> This is because the mandatory lenght indicator is enough to find the
> start of the next payload.
> In this case, why even use the PUSI pointer for the first tart in the
> TS-cell ? for I think lenght indicator + cell_numbering should be
> enough ?).

Would be so, assuming total synch. But if you loose/miss a TS Packet, then
you rely on these hints to get resynch. They also substantially improve the
ability to detect mis-alignment due to implementation errors.

> Did I miss something or is this pointer removable ?

No, this is required in MPEG-2.

> 
> 7) About address scoping
> I don't really see the point in managing sort of scope indicator
> at DVB-level, to manage muliple IPv4 private addressing that overlap.
> Indded, it may be out of context, and if we asume the DVB link a
> sort of publi link, overlapping addresses space should be managed
> at IP-level (with virtual routers or whatever).
> Or is it foreseen to addres a sub-PID managemùent, i.e. to do view a
> PID as a LAn, and to perform sort of VLAN management.
> 
We need text from people deploying links to give some clear "use cases" so
we can identify what is needed. If you have use-cases send them to the list,
and we can add them to the AR or architectural requirements Ids.

> 8) p23end of the page :
> excuse my ignorance, but what is the bandwitdth commonly associated to a
> single PID ? because can really  a few Mbps recpetion (destined to be
> filtered at IP level) be considered as a DoS ?
> 

This is purely a layer 1 (PHY) issue, if we change modulation, coding,
channel we are using, etc. Examples may be 1-100 Mbps the rates could
increase beyond this, or be much smaller. The IP technology needs to work in
all cases.

> Even in case of a router, and strange protocol behaviuour, report, to 7)
> 
> 
> Thanks for having read so far ....
> Regards.
> 
> Alain.