[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments about the Web document
I've included comments from Torsten Jaekel, and my responses. Other list
members and ID authors may have more to add... if so, please do send
comments to the list.
Torsten.Jaekel@FTK.rohde-schwarz.com wrote:
>
> Dear Mr Fairhurst,
> dear members of this email list,
>
> I whish you a Happy New Year, all the best for you and great success in your
> profession and private life.
>
> I have promissed to make my comments regarding the document
> draft-fair-ipdvb-req-00d.txt which is placed on Gorrys
> IP-DVB web site. Xmass gave me leisure and spare time to do it.
>
> Please find the doc file containing the original text and my comments.
>
> Best regards
>
> Torsten
<snip>
> email: Torsten.Jaekel@FTK.rohde-schwarz.com
>
> (See attached file: draft-fair-ipdvb-req-00d_TJ_comments.doc)
>
------------------------------------------------------------------------
> In section 1, Introduction
> TJ: What does the layered structure DVB-T->TS->Table Sections->MPE-IP
> mean ?
GF: MPE uses DSMCC sent as table sections, I'll amend the figure 1 to
show this more clearly. Is this correct?:
Please view below table in a fixed-width font such as
Monaco or Courier.
+---------+-+-+-+-+------+---------+--+--+--+
| |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 |Table Sections|
+---------+-------+----------+--------------+
| MPEG-2 TS |
+-------+-------+-------+-------------------+
| DVB-S | DVB-C | DVB-T | Other PHY |
+-------+-------+-------+-------------------+
> In section 1, Introduction
> TJ: DSM-CC is missing or is this meant by Table Sections ?
> (Table Sections for my understanding are used as signalling tables,
> not for data)
GF: Yes, see above.
> TJ: The layer IP->AAL5->ATM->MPEG-2 TS->DVB-T is strange here. It could mean
> the return path (uplink) in CableModem systems.
GF: This is permitted. I've seen it done in some return channel systems.
> TJ: Should this proposal cover also bi-directional broadcasting systems ?
YES, I think we should make it flexible enough to cover this.
> TJ: I think the difference between DVB-RCS, DVB-RCC,
> DVB-RCT should borne in mind.
GF: Given this operates above the MPEG-2 layer, are there implications which
impact the way IP is carried? - If so, can you help explain this?
------------------------------------------------------------------------
> In section 1, para 5, Introduction the ID says:
> "In some cases,
> receivers may need to select transport streams from a
> number of simultaneously active TS Multiplexes and TS channels."
> TJ: This means we need a multi-RF front end in the receivers ? One
> transport stream or multiple is transmitted as one RF frequency
> (it could contain many programs or also an Multi-Program-TS).
GF: Yes. Suggest:
"To receive IP datagrams sent over a MPEG-2 transport multiplex,
a receiver needs to identify the specific TS Multiplex
(physical link) and also the TS channel(i.e. PID value of a
logical link). It is common for a number of MPEG-2 TS channels
to carry subnetwork Protocol Data Units (PDUs), and the receiver
must therefore filter (accept) IP datagrams sent with a
number of PID values, and must independently reassemble
each subnetwork PDU. A system which simultaneously receives
from several TS channels, utilise receiver hardware to filter
unwanted TS channels. Mist current hardware has a limit on the
maximum number of active PIDs (e.g. 32). In some cases,
receivers may need to select TS channels from a number of
simultaneously active TS Multiplexes. To do this, they need
multiple physical receive interfaces (e.g. RF front-ends and
demodulators)."
> TJ: 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.
GF: I can envisage cases where a receiver accepts TV and DVB SI tables
on one multiplex, but goes to a different multiplex for IP data. perhaps
there is also a case for sending multicast on a different multiplex,
since this is common to all receivers, while unicast is sent on the multiplex
appropriate to an individual receivers. I suggest we should try to
satisfy this need - unless it proves really complex, reverse engineering
such support after we define the protocol is almost certainly going to
be bad news...
------------------------------------------------------------------------
> In section 1, Introduction the ID says:
> "Some applications also envisage the concurrent
> use of other non-DVB IP channels."
> TJ: why a problem ?
> A receiver has to have handle several PIDs at the
> same time due to the tables
> (PMT, EIT, AIT, ?). If we transmit data (all IP) in one PID we could
> overcome this problem.
GF: sure sending all IP data on one PID fixes this, but then we can't
take advantage of the PID addressing to build more sophisticated systems
and all receivers have to filter all IP flows, and can not utilise
a PID filter to separate traffic.
> To receive
> all data (all IP connections) transmitted in many PIDs does not seem to
> me necessary. Such a "Pre-Filter" will help to reduce the processing power.
> Therefore a proper design which IP is travelling in which PID
> (IP-PID-Mapping, see also later) is needed.
GF: See revised text above.
> TJ: Is there a need for a new standard called RFC-UDLR ?
GF: I will add a reference to:
[RFC3077] E. Duros, W. Dabbous, H. Izumiyama, Y. Zhang,
"A Link Layer Tunneling Mechanism for Unidirectional Links", RFC3077.
This describes one way to provide such a service. The UDLR WG
is now also working on multicast and security issues, which may also
be applicable. This will be useful to track. There is no intention
implied to change RFC3077.
------------------------------------------------------------------------
> In section 1, Introduction (just above figure 2) the ID says:
> "a set of optional header components, and requires decoding of the
> control headers."
> TJ: What does "control plane" here mean ? Control plane for me: the
> signalling tables but there is not a multiplex with data, video or audio
> (these are on another PIDs).
GF: Definition is agreed. But, that is precisely the point, MPE uses
this framework to sent IP (and Ethernet) data. This seems wrong,
it should be sent in the data plane, not using table sections. Hence,
I hope we will be able to define a new encapsulation to supplement
MPE which is tailored to the IP needs.
> Final para section 1 of the ID says:
> The framework proposed in this document describes a set of
> protocols designed to allow IP datagrams to be sent over an MPEG-2
> TS. These need to be simple and robust and shall have good link
> efficiency (i.e. small overhead) when transporting variable sized
> IP datagrams. The document also suggests the need for supporting
> protocols (e.g. to support operation and configuration of the
> link, provide resolution of the MPEG-2 Transport Stream (TS),
> error reporting, etc). The framework may also be applicable to
> other subnetworks utilizing the MPEG-2 Transport Stream, and
> similar links (e.g. non-DVB MPEG-2 transmission networks,
> regenerative satellite links [ETSI-BSM]).
> TJ: Great idea.
> Then it should also cover sound broadcasting links like
> DAB, iBOC etc.
GF: Yes, I am adding references to ATSC. If there are
specific issues or needs that you know of for DAB, etc, please
tell us more.
> TJ: What are Non-MPEG-2 TS similar links ?
> MPEG-2-Video over ATM could be
> such a system but there is LAN or CLIP to combine IP (more in a native
> way). I think this approach here is just useful for MPEG-2 based
> transmissions independent on the approach how this MPEG-2 is
> transmitted. Otherwise the parallel transmission on a bearer or carrier
> in a native manner can be discussed instead of IP encapsulation.
GF: This paragraph needs re-written. I'll rewrite it.
------------------------------------------------------------------------
> Section 2 of the ID TS multiplex is defined:
> "TS Multiplex: A combination of MPEG-2 transport streams sent over
> a common physical link (i.e. a transmission at a specified symbol
> rate, FEC setting, and transmission frequency)."
> TJ: a combination of ? streams can also be done by MPTS (Multi-Program
> TS). Is this meant ?
> Otherwise, the broadcast of many TS in parallel on different carriers
> (in case of DVB-T or DVB-C) or on parallel transponders (actually also
> frequencies and channels in DVB-S) is not a multiplex.
> A TS Multiplex is more the combination of (digital) audio, video, data
> and signalling information within one Transport Stream.
GF: What you say is what we meant to write, we'll revise the text.
Is this better?;
"TS Channel: a channel identified at the MPEG-2 level; it represents
level 2 of the ISO/OSI reference model. All packets sent over a
channel carry the same PID value
TS Multiplex: A set of MPEG-2 transport stream channels sent
over a single common physical link (i.e. a transmission at
a specified symbol rate, FEC setting, and transmission frequency).
TS: Transport Stream [ISO-MPEG], a method of transmission at
the MPEG-2 level using TS packets; it represents level 2 of
the ISO/OSI reference model. See also TS Channel and TS Multiplex."
------------------------------------------------------------------------
> Section 3 of the ID says:
> "This section describes existing solutions and the need for a new
> framework. This framework may be used in the forward and/or the
> reverse direction. The protocols to be supported over this link
> are:
> (i) IPv4 Unicast datagrams
> (ii) IPv4 Broadcast datagrams to all end systems in an IP network
> (iii) IPv4 Multicast datagrams
> (iv) IPv6 Unicast datagrams
> (v) IPv6 Multicast datagrams
> (vi) Datagrams with compressed IPv4 / IPv6 packet headers (e.g.
> [RFC1114;RFC2507;RFC3095])
> TJ: I have seen that the ATSC Datacasting document A90 deals with IPv4
> as well as IPv6.
GF: In IP over Ethernet, we normally separate these using the Ether-Type field
(assuming DIX format ether frames) - this simplifies the way drivers
process the packets. MPE and ATSC (i.e. A/90) both mention they work
for IPv6, but I don't see a clear description of how this should be done.
In DVB data transmission, I haven't seen any explicit mention of this.
In ATSC, it seems (to me - tell me if I am wrong) that this is primarily
aimed at a system which uses IPv6 OR IPv4 for control information (resource
descriptors) for sue be (for example) set top boxes.
Is there an assumption that one PID only carries IPv4 or IPv6 (but never both?)
All future IP subnetworks must support these things - so must we also.
> TJ: Perhaps it could necessary to check the differences between DVB and ATSC
> MPEG-2 IP based data services. Unfortunately there are some, e.g. PSI
> (DVB) and PSIP (ATSC) in terms of video services.
GF: Yes especially for IP transport, and also ARIB (?). All inputs welcome.
------------------------------------------------------------------------
> Section 3 of the ID says:
> "(vi) Scalability. The framework must be efficient when used
> in both large and small networks. The size of a network
> using MPEG-2 transport may range from a pair of nodes, to one
> including millions of receivers.
> TJ: Hmmm, we are still talking about broadcasting (the main purpose of
> our network). Such a system has to be independent of the number of
> receivers. The current systems (DVB-T and others) are able to fulfil this
> Requirement. No needs to mention separately ?
GF: Yes, but remember the ID is for the IETF to understand the issues
to be studied and to tell IETF contributors and reviewers what our
context is. With this in mind, it is uncommon to find LANs which
exist on this scale, so it's good to mention.
------------------------------------------------------------------------
> Section 4 of the ID says:
> "(iii) TS Resolution. There is a need to signal the PID and TS
> Multiplex that is associated with each IP flow to the
> network layer at the sender and receiver (address
> resolution). To make such schemes robust to loss and state
> changes within the DVB subnetwork, a soft-state approach
> may prove desirable. This could, for example, be
> implemented via descriptors in the SI tables, or by a
> protocol similar to the Ethernet address resolution
> protocol (ARP)."
> TJ: Yes, to know on which PID is IP transmitted, seems to be necessary.
> I am not so familiar with DSM-CC, but I guess to know, there is a private
> DSM-CC section is marked. But perhaps you do not know which kind of data
> is it (IP or Non-IP). But in the A90 ATSC doc (and my book) I see tables
> containing LLC/SNAP flags and bits to mark IP V4 or IP V6. Perhaps
> solved ?
GF: IN DVB, MPE systems seem to assume that you will use
LLC/SNAP to carry an IPv6 datagram.
This gives access to a MAC source address (if needed)
and an Ethertype field.
> TJ: Otherwise to transmit and broadcast (in a dedicated PID or table) which
> IP connections (distinguished by their destination addresses), contained
> in the TS is for my opinion not a good idea: very complex routing and
> tables, very dynamic and what if we had re-multiplexers in an TS-path
> changing the combination of PIDs and IPs ?
So we have three options:
(i) Send it as a SI table, in the MPEG-2 control plane.
(ii) Send it as an IP table (e.g. using SAP) sent over an agreed PID
(iii) Use a query/response protocol (like arp) over an agreed PID
I'll amend the text to say this.
> TJ: But I see a need to find fast and secure the "data channels", the IP
> connections and this one what I want to
> use on my receiver. Especially instead to transmit all IP in one PID we
> want make use of many PIDs to separate IP sub-networks (logical IP
> network grouping) it is necessary to have such a Map Table. But perhaps
> it is enough to do it on sub-network layers using the sub-network mask
> instead of single IP addresses.
GF: Indeed we should think carefully about encoding the table/query
so that it scales to large networks.
------------------------------------------------------------------------
> Section 4 of the ID says:
> "(iv) IPv4 and IPv6. The framework must support IPv4 and IPv6
> network protocols. The payload encapsulation may require a
> type field in the subnetwork PDU to indicate the type of
> the PDU being carried (e.g. IPv4, IPv6).
> TJ: Should not be a problem. As mentioned above, in ATSC A90 the
> differentiation between both version seems to me considered.
GF: I think there are still issues, see earlier.
> Section 4 of the ID says:
> "(v) Compressed Headers. The framework must address the need in
> certain applications for the support of header compression
> schemes. This may require a type field in the subnetwork
> PDU to indicate the type of the PDU being carried (e.g.
> IPv4, IPv6, Compressed Header).
> TJ: Instead of Header Compression my "dream" is to adopt the idea of
> MPLS, to have short tags at the ingress port and to have a mapping from
> IP (and sub-networks) to dedicated PIDs and using Tags instead of IP
> headers). Perhaps the same like IP header compression. But the result:
> The egress port has to know the mapping and needs this table (and
> routing info). A new, additional protocol is needed.
GF: Well, we've discussed this before, and I think you could map
MPLS to this subnetwork, if you so wished. My feeling is that MPLS
is sufficiently complex, that if you wanted to do this, we should
first start with a simpler native mapping, and then as we understand
this, you should write an ID (with any co-authors). This way we
can see if this can be done efficiently.
Note - MPLS ADDS overhead to simplify forwarding decisions, it
is NOT a header compression scheme.
As regards, Header Compression, ROHC is making good progress on
schemes which are sufficiently general to be applicable. I hope
that such schemes will be widely implemented in future systems,
and they therefore NEED to be addressed. This impacts "packing"
of data into MPEG-2 TS cells/packets.
> TJ: Be be more efficient can be reached if we compress the higher layer
> content. The upper layers, especially HTTP, SMTP, FTP waste more
> bandwidth, definitely I am sure. To compress also the application data
> instead the lower layers seems to me more beneficial.
> I have read that HTTP 1.1 is able to support compress content (using
> GZIP algorithms).
> An application and service oriented approach to discuss this issue seems
> to me necessary instead to talk just about a very low layer.
GF: Yes, this could be recommended if we publish a guidelines document,
but from the network point of view, there is little that can be
done with data already sent by a host. Such schemes seem out-of-scope
to me, unless other people say different on the list. We could refer
to IPCOMP etc.
------------------------------------------------------------------------
> Section 4 of the ID says:
> "(vi) Multicast. The framework must support IP multicast
> transmission of IPv4 and IPv6 datagrams. Support for
> broadcast must also be considered for IPv4."
> TJ: Where is a problem ? Unicast or multicast from the view of the
> transmission is just another 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 ?
GF: I can think of three things:
(i) The network doesn't know which subnetwork receivers wish to receive
the stream, a group membership protocol (e.g. IGMP / MLD) or routing
protocols (e.g. PIM) is needed.
(ii) There is potentially a very large set of multicast data which may
be sent over such a system, so the filtering task can be greater.
The address overlap between L3 (IP) and L2 (MAC) addresses can also
complicate things.
(iii) The multicast groups required by a receiver may be in different
TS multiplexes, which would not normally be the case for unicast.
> TJ: As I know multicast in the networking world (LAN, Internet) is still
> unresolved. There are three different approaches and their main problem
> is the traffic load, balance and routing (perhaps also to handle the
> return channels in case of point-to-multipoint which becomes multi-point
> to point in backward direction, I belive ATM tried to cover this). Which
> one will be the best fitting one for this focus here (perhaps PIM) ?
GF: PIM-SM is probably a good choice, if you are interested, I suggest
you track work in the UDLR WG of the IETF. Not sure of the implications
on the IP signalling, but hopefully the UDLR WG will have made progress
by this date.
------------------------------------------------------------------------
> Section 4 of the ID says:
> "(vii) Frame size and fragmentation. Specification of minimum and
> maximum frame sizes (MTU). The need (or not) for IP
> fragmentation and transparent fragmentation to support the
> minimum MTU [RFC1191;Ken87;LINK-ID]. There is no currently
> anticipated need to support IPv6 Jumbograms."
> TJ: What does minimum frame size mean ?
GF: IPv4 and IPv6 have minimum MTUs which ned to be supported.
> TJ: The MTU is more an issue of the highes layer of IP or "outside" our
> system. You can configure the MAX_MTU_SIZE in most of the operating
> systems (Windows, UNIX) or in a router. There are already some articles
> in the press dealing with the optimisation of system setting for IP via
> DVB. It should be possible to setup an MTU size in your generation
> device that the perfect filling of MPEG TS packets is guaranteed.
GF: Precisely, I think this is BAD. We can talk this through.
My suggestion
------------------------------------------------------------------------
> Section 4 of the ID says:
> "(viii) Identification of subnetwork source/destination. A new
> encapsulation scheme may need to support layer 2 addresses
> (e.g. Ethernet MAC source and destination addresses) of
> nodes in the MPEG-2 transport network. These are not
> required for layer 3 functionality, and the need, and
> applicability, must be addressed by the framework.
> TJ: Yes, I agree, the need for a standardized,
> machine controllable and
> dynamic mapping of IP<->PID is needed. This could be used for
> sub-networking grouping using PIDs but also for Unicast-Multicast
> separations etc.
> Unfortunately there is not yet a protocol to design such Datacasting
> networks. We see this demand and looking for a system (Enhanced
> Datacasting System, EDS) which offers a standardized, open interface
> To have access to a broadcast system (DVB, DAB, perhaps also WLL or
> WLAN) to allocate channels,
GF: OK, seems useful.
> To setup services and to manage bandwidth, quality and resources
> (channels, PIDs etc.).
> In DAB we have STI (service transport interface) what we are missing in
> DVB systems. Our MediaRouter should overcome this situation.
> Therefore: this and some other issues are also the main interest of our
> ideas and intentions.
GF: Your input on DAB could be useful here. I see this as
signalling from the MPEG-2 network with the upstream sender,
indicating (negotiating?) capabilities. This could be interesting.
------------------------------------------------------------------------
> Section 4 of the ID says:
> "(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).
GF: Yes, I can see cases for CA being used with the IP service.
Most IP service provision will have some return-path from the receiving
end host to the sending end host, and IPSEC (or SSH, TLS, etc) could
also be used, and should be permitted.
I suggest we follow the recommendations given in the PILC WG subnetwork
designer's document, ed by Phil Karn.
------------------------------------------------------------------------
> Section 4 Payload CRC:
>
> JT: The FEC is very powerful. Otherwise each layer brings his own
> checksum (also IP). Why there is a need ?
GF: The IP checksum is no use at detecting transmission errors, it's not
strong enough in an error-detection sense.
IPv4 has a header checksum, and anyway IPv6 does not.
So this doesn't help.
GF: Second part of the question is the FEC good enough. I would
argue that no it isn't. Given the pain of sending corrupted data into
the user's file system (where it sits as corrupted files, directories,
etc) it is only fair to protect this using a CRC. Others may disagree
we can debate this on the list, if we wish!
> JT: See ATM, the higher layers are in charge to solve
> transmission problems, not the link layer itself (the complex
> and overloaded X.25 is dead due to this approach ?)
GF: Yes, but ATM uses a strong (32-bit) CRC at the AAL5 level to do
exactly this task - to verify the framing of the received packets, and
to ensure they do not contain undetected errors left behind by the
FEC protection at the cell level.
------------------------------------------------------------------------
> In section 5:
> 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)).
GF: You are correct, tables used for signalling, sent in sections.
DSMCC used for control & control data, uses the same table syntax.
DSMCC also used to down-load firmware, guides etc.
DSMCC used by MPE as an IP bearer - this last step seems awkward to me.
> TJ: We use currently non-signalled IP transmission. It is not necessary
> to enhance the signalling tables in order to mark where your data
> service is. If you transmit IP independently of the table section there
> are just tow small problems:
> a) when you try to use an analyser you will find un-referenced PIDs and
> b) your receiver has to know exactly the PID where the data is carried
> (no dynamic and automated support)
> Otherwise to use a native, direct encapsulation into TS cells could
> disturb your main function, to transmit TV. How you could be sure that
> there is no influences when such a signal is passing the MPEG signal
> chain and devices (MPEG muxers, re-muxers, signal routers etc.) and that
> all the available receivers at the user side will interoperate with such
> a signal. It seems to me not possible to have a mix of native DSM-CC and
> direct mapping or it has to be investigated very carefully.
GF: Careful investigation is needed, but I suggest DSM-CC is not
designed for IP bearer networks. The needs of IP seem much nearer
to that of a PES than a DSM-CC channel. Finding a GOOD solution would
be a proposed task of the WG. I suggest we ask for suggestions in the form
of IDs and evaluate each in turn to see the merits and demerits.
------------------------------------------------------------------------
> In summary
> "This document proposes a framework for defining a set of protocols
> to perform..."
> TJ: Oh, configuration of the sender:
> a) How to do if we have just a uni-directional TS link down to the
> receivers ?
> b) The receiver should be configure itself (automatic adaptation to the
> signal, frame structures and parameters -> the idea of MPEG encoding and decoding).
> c) If a receiver could configure a sender -> dangerous. We have still a
> broadcast system and not an individual communication system,
> peer-to-peer.
GF: point taken, but remember some network service providers do in fact
use DVB purely as a lower-layer for IP data transmission - they COULD have
different needs. let's hope we can find a good general solution.
> There must be a guarantee that "all" receivers will be
> able to get the signal. The setup a "private", "strange" parameter
> profile for the source site done by a single end user is not anymore a
> broadcast capable system.
GF: Scaling issues may also suggest this is infeasible.
------------------------------------------------------------------------
> TJ: Additionally aspects in which we are interested:
> - open access interface to make us of broadcast system to
> transmit data common interface to setup services and
> connections, resource allocation and management (EDS)
GF: Interesting - the IETF is only responsible for protocols,
maybe ETSI could build on this with DVB help?
> - How to renegotiate existing services and parameters
> (dynamic service modifcation)
GF: QoS - yes would be good to work on this.
> - Object oriented service management and handling
GF: Not an IP issue (or is it?)
> - Quality of Service, service categories, priorities,
> transmission parameters, profiles etc.
> - Traffic shaping (smooth the traffic coming from
> burst-capable networks such as LANs when it enters a
> constant bit rate network such as DVB),
> estimation of shaping queue sizes, calculate the minimum
> and maximum throughput (automatic adaptation to the data
> generator profile)
GF: QoS - yes would be good to work on this, suggest after
the initial goals.
> - Mapping of IP and PIDs, signalling where the IP is
GF: Yes - within the proposed charter.
> and what kind of application (streaming, web, ftp, ?),
> sub-network grouping, PID-Rerouting
GF: Some of this hard, but's it's related to QoS
> - Hand-over mechanisms for mobile data reception (there
> should be a task force and some proposals), relation
> between backbone routing and dynamic
> service instantiation on transmitters in case of moving receivers.
> Hand-over when a receiver enters a new multiplex island (with another
> multiplexes and RF-channels).
GF: Put this way, this doesn't seem an IP issue itself, but
there are probably implications as such systems are defined.
> - The meaning and importance of MAC addresses, the resolution
> and mapping of MAC addresses (IP address can be manipulated,
> not useable as unambiguous destination addresses.)
GF: Yes - within the proposed charter.
> - Aspects of heterogeneous networks (the effect of changed MTU
> for one segment but end-to-end efficiency ?)
> - Higher layer data compression (ZIPed HTTP, FTP)
GF: These are design issues.
> The issue of the IP-PID-Mapping seems to me the main focus
> covered by this document what meets the necessary improvements
> of Datacasting systems what we see as well.
> If we need just a new optimised encapsulation procedure
> ? I do not think so.
GF: I can see some merits.
> We need end-to-end approaches, system design rules, access
> interface, service management. This has to be done by a strict guarantee
> of the interoperability with running systems.
> Perhaps a lot of standards
> and protocols exist (IP header compression, UHTTP, HTTP 1.1 with
> compression, MPLS, ATSC A90) which we can incorporate.
------------------------------------------------------------------------
I will do a revision of the text based on this, and collect any other
feedback from the list. Then I propose to submit as a first (-00)
Internet Draft. I am aware that we will probably need to make many revisions
and reorganisation of the document before we can make an RFC - so this is
just the first of many ID versions.
Bets wishes, and thanks for the detailed comments.
Gorry