Comments on draft-cantillo-ipdvb-S2encaps-00.txt

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

I think the draft is useful and I look forward to seeing this draft
discussed the draft at the WG meeting on Wednesday.  Ahead of this, here are
my comments on the current draft text.

I wish also to encourage others interested in this topic to read & review
the document and offer their own comments/questions to the ipdvb list. I'd
be interested to see the level of interest in this particular topic.

Best wishes,

Gorry

----

1) The draft describes a set of requirements in sections 4,5 some of which
resemble those already discussed in the ipdvb WG.

It would be good to more clearly set out what requirements that were
identified for MPEG-2 transmission of IP do NOT apply for DVB-S2, and to
list the places were there are differing requirements for DVB-S2.

A useful for basis for this is the WG document on Framework/architecture:
draft-ietf-ipdvb-arch-04.txt

* Can you clarify the places were see the requirements differ to those
listed in section 4 of the arch document?

----

2) At the end of section 3, the draft states that "The main advantage
is...". From my understanding, I am not sure that this captures the complete
picture.

While simplification of the encapsulation process clearly has architectural
benefits and reduces the system complexity, the gain in performance is
likely to be limited - the overhead of the MPEG-2 TS multiplexing layer is
(4 or 5)/188 bytes, around 2%: Eliminating this is unlikely to yield much
overall gain in overall link efficiency.

If this were the only motivation, I would have concerns whether this work
could be justified.  However, I believe that the introduction of adaptive
coding and modulation in DVB-S2 raises new issues that could motivate a new
encapsulation. 

For example, the physical layer framing is different, and is used in a
different way - particularly since specific frame formats will be used to
communicate with Receivers based on Receiver characteristics (terminal
design, location, SLA, etc) and/or upon prevailing channel conditions. This
usage differs from the stream-based approach of classical MPEG-2 TS.  As a
result, packets destined to an End System will be encoded in one of a set of
different physical layer frame formats. The format chosen will depend upon
the time (i.e. Prevailing system conditions) and the next-hop Receiver.

Two additional aspects are:

(i) The physical layer frame format allows much larger IP fragments, and
will often allow transmission of complete packets within single frames. This
may have implications on the design of the encapsulation.

(ii) A case exists were a fragment of a particular IP packet sent in a
previous physical layer frame may (or may not) be resumed in the next
successive physical layer frame. If it is not sent consecutively, it may be
postponed to a later physical layer frame.  This case could arise if
transmission would otherwise result in a partially full physical layer frame
(other traffic may not be suited to this frame format, if this frame did not
meet the SLA requirements of the other queued traffic). This seems to imply
a need to look at more advanced fragmentation procedures than currently
implemented in ULE.

* Can you (or others on the ipdvb list) offer views on these issues? I'd
like to understand better these issues, to judge what level of complexity is
actually required by an "S2 encapsulation protocol".

-----

3) In addition, resolution methods are required to map the IP flows to
physical layer flows. If the MPEG-2 TS is used, these may resemble those
currently proposed in:
draft-ietf-ipdvb-ar-00.txt

* Are there important differences?
* What is the expected impact of directly using the Generic Mode rather than
the MPEG-2 TS?

-----------------------------------------------------------

The following editorial NiTs may be worth correcting in the next draft:

----
(a) The Introduction & references should cite:

   [RFCXARCHX]  M.J. Montpetit, G. Fairhurst, H. D. Clausen, B.
   Collini-Nocker, H. Linder "A Framework for transmission of IP
   datagrams over MPEG-2 Networks", RFCXARCHX, 2005.
   <currently draft-ietf-ipdvb-arch-04.txt, RFCEd queue>
----
(b) It would be most useful to include a set of definitions for the terms
that are used relating to the DVB-S2 layer (e.g. A section on "Conventions
Used in This Document" would be welcome).
----
(c ) There is a missing blank line between refs 3 & 4.
----
(d) At some time, references need to be divided between normative and
informative. My suggestion is the following (although this may depend upon
how the document evolves):

Normative 1,3,6
Informative 2,4,5,7,8 9
----
(e) The use of RFC2119 key words in this context (as a requirements
document) may not be appropriate, but this can be resolved at a future time.
----