Re: Draft for ROHC over DVB - comments on your text.

[Ang Way Chuang <wcang@nav6.org>]

Dear Dr. Gorry Fairhurst,

Sorry for the late reply. I hope you are okay with the inlined reply.

Gorry Fairhurst wrote:
> I have a few questions about the draft from the ULE perspective, please 
> see below.
>
> Gorry
>
>
> ---------------------------------------------------------------------
>
> 1) ULE Type
>
> There are two ways the Type field could be used, and I am not clear 
> which you are proposing.
>
> a) You could use a ULE Mandatory Extension Header. The value for this 
> could be allocated by the IETF, if this were approved as an IETF RFC and 
> that would certainly be one way to proceed that would allow you to embed 
> ROHC functionality in the ULE/GSE Gateway and Receivers.
>
> b) You could apply to the IEEE for an EtherType value from the IEEE 
> Registry that would be applicable to all IEEE technologies (WiFi, 
> wired-ethernet, etc) and which naturally could be used with ULE/GSE 
> also, although you would still need to define how this was implemented, 
> and how this interacted with ULE if you wanted to embed the compression 
> and decompression in the ULE end-points rather than in the connected end 
> host Ethernet drivers.
>
> (it's a little wrong to speak of a "IANA assigned EtherType number" - 
> since this mixes the two possibilities).

Oh I see. What are the financial implications for approach a and b? I 
assume that b is harder and may take longer to get approval.
1) I think b is more desirable since it applicable for ULE/GSE and UDLR.

2) If getting a EtherType from IEEE is not feasible, then we may need to 
resort to change the format of the ULE payload to accommodate the source 
address if necessary.

> Comments and questions relating to this:
>
> ---
> In section 3.1.2:
>
> I don't understand the header format. The base-header has the type 
> Ethernet - this means the encapsulated PDU must be an Ethernet Frame (as 
> per RFC4326). A receiver should attempt to forward the PDU to the 
> bridged LAN interface.
>
> If you wanted a compressed ROHC payload in bridged mode, you'd probably 
> need to define a new ULE-Type that denotes you are carrying a bridged 
> ROHC PDU that needs to be decompressed prior to Receiver bridge 
> processing - you probably also need to describe how this would work.

3) Yes, the ideal case is to get IEEE EtherType for ROHC, so that it can 
be used for Bridged Frame (Type = 0x0001).
> ---
>
> In Section 4.1:
>
> "Since new EtherType is allocated, this
>    protocol can be extended to asymmetrical link via Link-Layer
>    Tunneling Mechanism [RFC3077]"
>
> - UDLR uses IEEE EtherTypes, whereas ULE uses these, but includes its 
> own extension formats. So this is only so, if you request an 
> IEEE-allocated Ethertype, rather than a ULE-Type value from the IANA 
> extensions registry.

4) Yeap, so it can't get work without IEEE EtherType.

> ---------------------------------------------------------------------
> 2) In Section 3.1.1:
>
> "In the absence of multiple receivers, a transmitter can send an SNDU"...
>
> I think this is only partially true, it may be safer to refer this to 
> RFC4326, since this is also dependent on the way in which the ULE Stream 
> is used.

5) I'm not sure whether I get your point correctly. Referring to section 
4.5, there is no point of using ROHC in multicast and broadcast. So it 
only make sense in unicast. But since the IPv4/IPv6 header is 
compressed, the receiver needs to distinguish its packet from others by 
looking at the Destination Address in the case where multiple receivers 
share the link. Is that your concern?

> ---------------------------------------------------------------------
> 3) In section 3.2 (ROHC over MPEG2-TS):
>
> - This format isn't clear to me, it seems you are trying to define a new 
> types of Stream, which I guess is possible, but that would imply 
> defining integrity checks, length, NPAs, etc - in much the same way as 
> ULE was developed. This would perhaps at most save 2 bytes, but would be 
> incompatible with the ULE framework. I'm not sure I understand the 
> motivation here.

6) Yes, you are right. The idea is to save 2 - 3 bytes for each ROHC 
compressed packet. But if the amount of effort involved does not worth 
it, we can drop this.  The whole idea is that is to let compressor site 
selects a PID as a unique channel between itself and a particular 
receiver. Of course, the advantage is more obvious if source and 
destination L2 addresses need to be included. By mapping a PID to a pair 
 of source and destination address, 12 bytes can saved per ROHC 
compressed packet.  But ROHC over ULE can also work in this manner.

> ---------------------------------------------------------------------
> 4) In Section 4:
>
> With the exclusion of section 3.2, this seems to apply to any ULE Stream 
> (and probably a GSE stream) - independent of the physical layer (DVB, 
> ATSC, or whatever).
>
> In Section 4.1:
>
> Again, with the exclusion of section 3.2, this could be applicable to GSE.
> ---------------------------------------------------------------------

Okay.

> Best wishes,
>
> Gorry
>
>
> I also have a few minor editorial comments (which may be helpful if you 
> decide to prepare an updated draft):
>
> ---
> Change
> /ULE stream/
> to
> /ULE Stream
> ---
>
> It would seem worthwhile drawing the diagrams in the same representation 
> as other ULE Extensions, using the 32-bit wide format of:
>
>
>        0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |D|        Length  (15b)        |         Type = 0x????         |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> ---
>
> I'd suggest creating a two reference subsections, one
> "Normative References"
> and one
> "Informative References"
>
> I'd suggest replacing GSE with the ETSI Specification reference:
>
>    [GSE] TS 102 606 "Digital Video Broadcasting (DVB); Generic Stream
>    Encapsulation (GSE) Protocol, "European Telecommunication Standards,
>    Institute (ETSI), 2007.
>
> I'd suggesting a normative reference to:
>
>    [RFC4326] Fairhurst, G. and B. Collini-Nocker, "Unidirectional
>    Lightweight Encapsulation (ULE) for transmission of IP datagrams
>    over an MPEG-2 Transport Stream", RFC 4326, December 2005.
>
> I'd suggest placing the following as Informative references :
>
> [DIX]
> [ISO-MPEG2]
> [ITU-H222]
> [RFC3077]
>
> You may like to provide an informational reference to the following for 
> terminology and architecture:
>
>    [RFC4259] Montpetit, M.-J., Fairhurst, G., Clausen, H., Collini-
>    Nocker, B., and H. Linder, "A Framework for Transmission of IP
>    Datagrams over MPEG-2 Networks", RFC 4259, November 2006.

Okay, noted. Thank you very much for your feedback. I shall try to send 
an updated draft within this 2 weeks.


Regards,
Ang Way Chuang