[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Further comments on the proposed RFC
+++++++++++++++++++++++++
Thanks for your comments, these are most welcome.
I've copied the text from them below. The normal form
for IETF mailing list differs from many other standards bodies, and
usually comments are sent text-only to allow all list members to
read them. For those on the list who can't read .doc format, here are
the original comments with my comments (marked GF) added.
Best wishes,
Gorry Fairhurst
"Walsh Rod (NRC/Tampere)" wrote:
>
> Hi All
>
> Please find attached the Framework proposal with further comments from
> Rod Walsh and Juha-Pekka Luoma of Nokia. (T. Jaekel's earlier comments
> are also in this from a previous circulation).
>
> We hope these are valuable and look forward to participating in the
> success of this work.
>
> Best regards
> Rod Walsh,
> Nokia Research Center
> Tampere, Finland
> rod.walsh@nokia.com
>
<<snip>>
------------------------------------------------------------------------
> Abstract
> RDW: ATSC and ISDB-T could be mentioned here if these are within scope!
GF: YES, based on what was said at the meeting in SLC, I have started to
generalise the text to refer to MPEG-2 where possible, with examples
from DVB and ATSC - we could mention others too, if there is experience
with these, and documents that are available to this list.
------------------------------------------------------------------------
> After figure 1:
> RDW: I understood that the above figure refers to forward path
> only. It would help clarity if protocols for the DVB forward
> path and various return paths are presented in separate figures.
GF: Yes, do we need a different one for the return path too?
> RDW: Also, DSM-CC Sections has more meaning than Table Sections,
> or is there na specific reason that "Table" is chosen?
> For example DSM-CC sections (including datagram sections)
> do not constitute a table.
GF: I'll just call them sections if it is clearer.
So.... in the rev I am writing, I now have:
+---------+-+-+-+-+------+---------+--+--+--+
| |T|V|A|O| O | |O |S |O |
| |e|i|u|t| t | |t |I |t |
|Other |l|d|d|h| h | IP |h | |h |
|protocols|e|e|i|e| e | |e |T |e |
|native |t|o|o|r| r | |r |a |r |
|over |e| | | | | | |b | |
|MPEG-2 TS|x| | | | | +---- +--+l | |
| |t| | | | | | MPE |e | |
| | | | | | +--+---+--------| | |
| | | | | | | AAL5 | DSMCC | | |
| +-+-+-+-+---+------+--------+--+--+
| | PES | ATM | Sections |
+---------+-------+----------+--------------+
| MPEG-2 TS |
+-------+-------+-------+-------------------+
| DVB-S | DVB-C | DVB-T | Other PHY |
+-------+-------+-------+-------------------+
Is this as it should be?
------------------------------------------------------------------------
> RDW: MPEG2-PSI also reserves some PIDs (PAT has 0x0000,
> CAT has 0x0001). I have several times read the comment that
> although is PSI clearly defined in the MPEG-2 systems standard and
> SI in the DVB standards, the two terms are used "interchangably".
> I would rather keep the two separate in specifications, if possible.
> The term DVB-SI may be seen as ambiguous
> - "DVB-SI and MPEG2-PSI" is clear.
GF: I agree, I suggest at the moment to talk only about "SI"
in the most general sense.
(I shall remove references to MPEG-2 SI and DVB SI)
and will not differentiate the two (or talk about ATSC tables).
I suggest we change this to say that:
"The PID value is a 13 bit field and, thus, the number of
channels is limited to 8192, some of which are reserved
for transmission of SI tables."
and also say:
"In this document, the term "SI" is used to decribe any table
used to convey information about the service carried in the
TS Multiplex."
Is that OK, or would you like to suggest alternate?
------------------------------------------------------------------------
> TJ: This means we need a multi-RF front end in the receivers ?
> One transport stream or multiplex
> Is transmitted as one RF frequency (it could contain many
> programs or also an Multi-Program-TS).
> Why it is necessary ? Perhaps for mobile data reception it
> could be necessary to have a two RF frequency demodulator in
> order to scan the next channel on which we have to hand-over.
> By the way: I have heard such hand-over mechanism recently
> missing in DVB is already defined.
> RDW: On TJ's question, the text needs clarification,
> which meaning is intended?
> "In some cases, receivers may need to scan transport streams from
> a number of simultaneously active TS Multiplexes
> and TS channels before selecting one."
> or
> "In some cases, receivers may need to receive services
> on several transport streams which are from a number
> of simultaneously active TS Multiplexes and TS channels."
> RDW: the terms "TS Multiplex" and "TS channel" are not
> entirely aligned with DVB terms - "Multiplex" and "Transport Stream"
> seem to be what you mean - see EN300468.
> RDW: It seems that the specification writes about a
> "Transport Stream multiplex" as a plurality of "Transport Streams".
> I have understood instead that a Transport Stream is a
> multiplex.
GF: In the version I am working on (I'll send this out in the next
week, so everyone can look at it), a "TS Multiplex" is a
series of consecutive transport packets all sent over the same physical
link. This is a key term - we need to get the right name and meaning.
(I guess you're going to tell me more about DVB-T Cells later and we'll
need to add some more text to cover that).
Would that be OK?
> RDW: A DVB compliant TS consists of one or more DVB
> services, each consisting of one or more service components.
> In MPEG-2 Systems terms, one could write as well that a
> TS consists of one or more programs, each consisting of
> one or more program elements.
> RDW: I believe the term "TS channel" is not commonly used in
> MPEG-2 or DVB specifications - is it here aligned with a
> DVB service or service component?
> The DVB specifications only generally write about PIDs defining
> "logical channels" within a TS.
GF: see previous email for new text on these things.
The term TS Channel, was meant to align with the DVB terminology
and is a logical channel - simply labelled a "TS channel",
to avoid confusion with other logical channels we may come
across in other protocols.
Would "TS logical channel" be better, "TS Channel" is shorter?
> RDW: The term channel here is problematic.
> There is not a perfect DVB term for this but "component"
> or "service component" comes close. Also note, according
> to DVB definitions, a MUX is one TS (i.e. has one TS id),
> so these channels (when part of a MUX) are not TS's
> (even though they may have been before multiplexing)
> - they are "components" or "program elements"
> or "elementary streams".
> RDW: See earlier comment - I highly recommend using
> DVB terms where possible and unambiguous since mutual
> understanding is essential. It also refers time consuming
> terminology debates to a forum that has already been
> through that issue (for some terms).
GF: I'll write new text and see if we can converge.
------------------------------------------------------------------------
> RDW: Address collisions where, for example, the same
> multicast address is used on several different PIDs
> are more of a problem. It is worth clarifying the
> minimum number of PIDs that are required to be simultaneously
> filtered - so that vendors have a base figure.
GF: OK, we can add text on this issue. I will suggest some.
------------------------------------------------------------------------
> In section 2:
> MPE: Multiprotocol Encapsulation [ETSI-DAT]. A scheme that
> segments Ethernet frames or IP Datagrams into Sections, and then
> sends these using DSM-CC formatting over an MPEG-2 TS.
> RDW: MPE "embeds" or "encapsulates" to DSM-CC format.
> The MPE protocol does not "send". [The alternative acronym,
> "Multiprotocol Encapsulator", may be confused]
GF: Quite so. I suggest the following new text:
"MPE: Multiprotocol Encapsulation [ETSI-DAT]. A scheme that
encapsulates Ethernet frames or IP Datagrams creating a
DSM-CC Section. The Section may be sent in a series of TS packets
over a TS channel."
------------------------------------------------------------------------
> Definition of TS Packet: ...
> RDW: Stick to TS Packet. TS Cell will be confusing when the issue
> of multi-cell network arises.
GF: I wanted to mention the existence of the term "TS Cell", and
I do agree, and would prefer we only use "TS packet" in these documents.
------------------------------------------------------------------------
> Section 4:
> (ii) Minimal overhead. ...
> RDW: IP Packet size, version and frequency will effect
> efficiency. Will you define some real-world "test case"
> scenarios for different proposals to be quantitatively
> measured and compared?
GF: Nice idea!!! I'm not sure this IETF work, maybe it is?
- It would be useful to have an ID on this, so we could
evaluate how easy it would be to define benchmarking
terms and appropriate tests.
Your comments certainly raise an interesting validation
and performance question... what do others think?
------------------------------------------------------------------------
> Section 4:
> (vi) Scalability
> RDW: as above, how will each of these criteria be measured?
> (Separate RFC?) The framework and the assessment criteria
> are probably the only important deliverables at the first stage.
GF: - see above.
------------------------------------------------------------------------
> Section 4:
> (ii) Probability of undetected packet error. There should be a
> small undetected link error rate [LINK-ID]. The scheme
> therefore needs to be robust to software failures and link
> loss. The need for a subnetwork PDU CRC will be determined.
> RDW: Exchange "should" for "may" or "will probably"
> - otherwise it sounds like you are requiring that the link
> generates errors.
GF: I'll fix :-)
"There should be a small (or negligible) probability of an
undetected packet error [LINK-ID]."
------------------------------------------------------------------------
> Re: Multicast
> TJ: Where is a problem ? Unicast or multicast from the view of the
> transmission is just an other range of IP addresses. Due to the
> broadcast character of the MPEG TS link it supports both simultaneously.
> What is specific in terms of multicast ?
> RDW: The DVB specification (for MPE) leaves too much unresolved. IPv4,
> IPv6, unicast & multicast cases must be explicitly specified for
> interoperability (even if unicast and multicast address issues turn out
> to be identical) - if in doubt, consider that IPv4 multicast to MPE MAC
> mapping is specified (optionally).
GF: I agree
------------------------------------------------------------------------
> (xi) Security. The framework must permit the use of IPSEC and
> clearly identify any security issues concerning the
> specified protocols. Consideration should also be given to
> the need for closed user groups and the use of MPEG-2 TS
> encryption.
> TJ : Yes, security but we have to distinguish between Conditional Access
> (CA), a native approach to encrypt programs and content (perhaps it
> works also for IP) and IP encryption as function of a higher layer. If
> we say, OK IP security is the task of the higher layers, end-to-end,
> based on existing IP and software applications nothing have to be done.
> But just the "simple" fact, our system is mainly uni-directional !!! has
> to be borne in mind. A negotation of a key is not possible, the
> algorithm has to be work asymmetrically etc. Than we are back to the
> basics of CA where the source can allow that one of the receivers can
> make use of encrypted content based on an device ID (perhaps the MAC address).
> RDW: This requirement actually means that the framework must specify an
> (optional) return path. Cases of with and without return path must be
> considered. (Note, both IPsec and MSEC should not effect layer 2 or MPE).
GF: Do we need bi-directional (duplex) communication between end hosts to
use IPSEC - I thought providing you could distribute keys, one-way would
be fine --- can someone check this?
> RDW: CA is generally not seen as a good way to encrypt IP flows (see
> DVB-TM IPI2001-058r1). When using CA for IP traffic, sections should be
> encrypted (not TS packets - see ISO13818-1, headers of private sections
> must be sent unencrypted).
GF: So, if we are thinking of a new encapsulation.... we'd need to decide
whether there was a need for CA for IP data?
------------------------------------------------------------------------
> Section 5 para 2.
> TJ: Are the tables (the DVB signalling) transmitted in DSM-CC sections ?
> I do not think so, DSM-CC is just used for data (well known like Data
> Carousel or Object Carousel (used in MHP) or private (IP and others)).
> RDW: SI tables go in MPEG-2 private sections. DSM-CC section is a
> subtype of an MPEG-2 private section, but it is not used to carry SI tables.
GF: Well put, I'll add that to the definition text in section 2.
------------------------------------------------------------------------
> End of section 5, final para. The ID says:
> "The IP address resolution support may also be suited for use with
> other IP over DVB encapsulations (e.g., MPE [ETSI-DAT]). As part
> of address resolution, there is also a need to signal whether MPE
> or an IETF encapsulation is used"
> TJ. New for me. Which other IP-over-DVB encapsulations do exist ? I
> thought just DSM-CC with MPE, perhaps just to distinguish between DVB,
> ATSC (and the Japanese system IDBT).
> RDW: If a "sender" is a normal IP server, then I would not expect it to
> understand the DVB world. The framework should define the name of this
> "DVB Interface Unit" entity. [note, if MPLS is introduced, then the
> implications should also be considered here]
GF: OK, so the current ID doesn't say who does the encapsulation or
where a TS Mux is located, or anything like that... I guess some
figures would be useful...
> RDW: Related to this - is the "IP sender" to "DVB Interface Unit"
> interface also in scope? I have the feeling that these work items will
> need further review for the "IP server - DVB Interface Unit - MPE"
> (logical) architecture.
> Just for fun...
> +----------+
> | |
> | DVB |
> +----------+ |interface | +----------+
> | | | unit |-(?? control)-| |
> | IP |-(IP control)-| |-(IP control)-| IP |
> | sender | +----------+ | protocol |
> | | | encaps |
> | |----------------(IP data)---------------| |
> +----------+ +----------+
GF: :-),
but seriously,
some drawings showing what the component equipments are
encapsulator, mux, etc, would be a very useful addition to the next rev.
------------------------------------------------------------------------
> 6. Multicast Support, the ID says:
> "This section addresses specific issues concerning IPv4 and IPv6
> multicast over DVB links.
> These issues include, but are not restricted to:
> (i) Encapsulating multicast packets on the forward TS multiplex.
> (ii) Mapping IP multicast groups to the underlying network
> PID and TS Multiplex.
> (iii) Provide signalling information that allows receivers to
> extract an IP multicast flow from the TS Multiplex.
> (iv) Determining group membership(e.g. utilising IGMP / MLD).
> (v) Error Reporting.
> RDW: The term "TS Multiplex" causes problems again.
GF: Think this is a bad choice of wording, I'll rewrite it.
> What about
> remultiplexing. What about where the MPE generates elementary stream
> that goes to several multipexors (and also many MPEs per MUX).
> Encapsulation and multiplexing should be separated (functions), the
> later possibly happening several times before final "transmission ready"
> multiplexes are broadcast.
GF: I agree with what you say.
> RDW: (iii) "extract" should be "locate" - unless this is also to include
> extraction code or parameters. [I would expect that extraction happens
> according to a static definition (with options :) in the standard -
> location is dynamic].
GF: Good point.
> RDW: (ii) and (iii) seem to consider a single cell (multiplex) network
> only. Both DVB-T and DVB-S deal with multi-cell networks (although
> network management issues tend to be partially different). If the
> intention is to leave any or all of "IP session discovery, topology
> (cell availability) and maintenance (mobility, transponder changes
> etc.)" out of scope, then I think this should be explicitly stated to
> avoid confusion over what is included in "signalling information".
> Making service discovery a separate chapter would help.
> RDW: (iv) In general terms, IGMPv3 and MLDv2 are preferable due to the
> SSM capabilities.
GF: Agree. But this is a guideline for use, we must design the system
to work with IGMPv2, IGMPv3, MLD, MLDv2.... or none of these...
------------------------------------------------------------------------
> On small MTU size
> RDW: The header goes into each packet, so the smaller the MTU, the less
> efficient the protocol (for data transfer greater than 1 packet in
> length). IP packets can of course be smaller than the MTU, whatever the
> MTU size. The current DVB MPE already allows multiple small IP packets
> to be packed to a single TS packet using section stuffing, defined in
> MPEG-2 Systems as an optional feature (worth implemeting if efficiency
> is a goal).
> RDW: the TCP ACK is a bad example for the forward path, but we must not
> exclude messaging services (small data blocks) - which generate revenue
> in many business cases!
GF: Agree
------------------------------------------------------------------------
> CRC or no CRC?
> RDW: IPv4 has a 16bit header checksum, IPv6 does not. I agree with TJ,
> you can have RS FEC with DVB, or otherwise implement FEC at layer 4 or
> above (e.g. uHTTP). 3G does allow link layer retransmissions (RUP), but
> that's not unidirectional.
GF: I think, if we were to have no CRC we would need to be very clear
in our assumptions, current guidance is to have one. I suggest we make this
an issue to be determined.
------------------------------------------------------------------------
> (viii) Error Reporting. (ICMP messages should be sent where there
> is a known return path according to normal internet
> practice).
> RDW: which ICMP messages? The could be a "may" rather than a
> "should" requirement.
GF: OK, "(viii) Error Reporting. If an equipment is an IP device,
then it should conform to standard requirements for hosts
[RFC1122] or routers [RFC1812] (depending on its behaviour)."
------------------------------------------------------------------------