Subject: Adaptation field use in ULE / MPG2-TS specification

From: Tor Brekke <[email-masked]>
Date: Tue, 13 Apr 2004 09:02:37 +0200

Hello, 

I am jumping into this discussion at a fairly late stage. Having just read 
the ULE draft I have to make a comment about the use of the adaptation 
field though. In the draft it says that "TS Packets from a ULE 
Encapsulator MUST be sent with an AFC value of '01'", i.e. without 
adaptation field. Now the adaptation field contains a private field which 
according to the MPG2-TS specification (ISO/IEC 13818-1) can be used to 
transmit system dependent data. 
Now to the question: Why is this limitation imposed on ULE? 

I have two main reasons to ask this. 
1) Firstly there is ongoing work to use the private adaptation field for 
network internal signalling in the DVB-RCS standard. This means that ULE 
will not work over DVB-RCS systems employing the adaptation field 
signalling. 
2) As far as I have been able to determine all other encapsulation forms 
over MPG2-TS are transparent to the adaptation field, i.e. the adaptation 
field and payload are handled independently (even though there may be an 
implicit connection between them). It seems strange to break this logicinf 
the MPG2- TS mechanism for a new encapsulation type. 

Best Regards
Tor Brekke
Nera Broadband Satellite AS.

---

From: "Marie-Jose Montpetit" <[email-masked]>
Date: Tue, 13 Apr 2004 06:29:30 -0400

Thanks for you input. If you follow recent discussions there is a proposal to use extension headers in ULE to support system specific signalling (and other). It would be interesting to know more about how you process the information but I think our philosophy would be to use the headers in the same way as you describe: transparent to system who do not know what to do with them, processed by the ones who do. This is consistent with IPv6 extension headers and also with other implementations of extension headers (cable for example).

So I do believe we could use ULE in RCS. Actually in a recent study sponsored by ESA we showed that for traffic with a lot of ACK bursts (http: for example) ULE was very efficient because of it's packing capability.

Again thanks for your input.

Marie-Jose

  ----- Original Message ----- 
  From: Tor Brekke 
  To: [email-masked] 
  Sent: Tuesday, April 13, 2004 3:02 AM
  Subject: Adaptation field use in ULE / MPG2-TS specification

  Hello, 

  I am jumping into this discussion at a fairly late stage. Having just read the ULE draft I have to make a comment about the use of the adaptation field though. In the draft it says that "TS Packets from a ULE Encapsulator MUST be sent with an AFC value of '01'", i.e. without adaptation field. Now the adaptation field contains a private field which according to the MPG2-TS specification (ISO/IEC 13818-1) can be used to transmit system dependent data.   
  Now to the question: Why is this limitation imposed on ULE?   

  I have two main reasons to ask this. 
  1) Firstly there is ongoing work to use the private adaptation field for network internal signalling in the DVB-RCS standard. This means that ULE will not work over DVB-RCS systems employing the adaptation field signalling. 
  2) As far as I have been able to determine all other encapsulation forms over MPG2-TS are transparent to the adaptation field, i.e. the adaptation field and payload are handled independently (even though there may be an implicit connection between them). It seems strange to break this logicinf the MPG2- TS mechanism for a new encapsulation type. 

  Best Regards 
  Tor Brekke

---

From: Tor Brekke <[email-masked]>
Date: Tue, 13 Apr 2004 13:15:33 +0200

I believe we are talking about two different levels of signalling here. I 
am concerned about using ULE over systems which use the MPG2-TS adaptation 
field for system internal purposes. The way the ULE draft is formulated 
this will be impossible. 

The use of ULE extension headers can not replace this signalling since it 
would require updates to already existing standards. In addition the 
headers are really on a completely different level since they are bound to 
an ULE packet. The adaptation field is part of the MPG layer. Signalling 
at this level should be independent of whether he MPG payload is ULE, MPE, 
SI, nothing (!)  or something else. 

I hope this has helped to clarify the concerns we have. 

Regards
Tor

---

From: "William StanisLaus" <[email-masked]>
Date: Tue, 13 Apr 2004 17:48:29 +0530

Hi Marie-Jose,
    I understand your point here about extension headers. But actually
Adaptation field specified here is part of MPEG2-TS header and not ULE, in
that case even ULE is a payload for MPEG2-TS. If adaption field control is
10 or 11 in bits, MPEG2-TS contains private adaption field, and incase of
"10" we need not care about anything, but still ULE draft says anything
other than " 01" in AFC, receiver MUST discard.
    Thanks for your comment Tor Brekke, but i wonder why we have such
limitation in ULE, even though we are not worried in ULE about the MPEG2-TS
private section of Adaption field, if we are not going to take any action
based on the adaption field and control field we can just ignore. I see this
as an implementation issue and should not be limited in specification/draft.

transport_packet(){
        sync_byte
8 bslbf
        transport_error_indicator
1 bslbf
        payload_unit_start_indicator
1 bslbf
        transport_priority
1 bslbf
        PID
13 uimsbf
        transport_scrambling_control
2 bslbf
        adaptation_field_control
2 bslbf
        continuity_counter
4 uimsbf
        if(adaptation_field_control=='10' ||
adaptation_field_control=='11'){
              adaptation_field()
        }
        if(adaptation_field_control=='01' || adaptation_field_control=='11')
{
             for (i=0;i<N;i++){
                 data_byte
8 bslbf
            }
       }
}

here N data_byte's is SNDU as specified by ULE.

Also ULE cannot limit anything on exisiting underlying protocol as such
MPEG2-TS. But definitly it can limit or provide more services to above
layers.

Best Regards,
William StanisLaus
CalSoft, Nortel Networks Division

  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On
Behalf Of Marie-Jose Montpetit
  Sent: Tuesday, April 13, 2004 4:00 PM
  To: [email-masked]
  Subject: Re: Adaptation field use in ULE / MPG2-TS specification

  Thanks for you input. If you follow recent discussions there is a proposal
to use extension headers in ULE to support system specific signalling (and
other). It would be interesting to know more about how you process the
information but I think our philosophy would be to use the headers in the
same way as you describe: transparent to system who do not know what to do
with them, processed by the ones who do. This is consistent with IPv6
extension headers and also with other implementations of extension headers
(cable for example).

  So I do believe we could use ULE in RCS. Actually in a recent study
sponsored by ESA we showed that for traffic with a lot of ACK bursts (http:
for example) ULE was very efficient because of it's packing capability.

  Marie-Jose

    ----- Original Message -----
    From: Tor Brekke
    To: [email-masked]
    Sent: Tuesday, April 13, 2004 3:02 AM
    Subject: Adaptation field use in ULE / MPG2-TS specification

    Hello,

    I am jumping into this discussion at a fairly late stage. Having just
read the ULE draft I have to make a comment about the use of the adaptation
field though. In the draft it says that "TS Packets from a ULE Encapsulator
MUST be sent with an AFC value of '01'", i.e. without adaptation field. Now
the adaptation field contains a private field which according to the MPG2-TS
specification (ISO/IEC 13818-1) can be used to transmit system dependent
data.
    Now to the question: Why is this limitation imposed on ULE?

    Best Regards
    Tor Brekke

---

From: "Marie-Jose Montpetit" <[email-masked]>
Date: Tue, 13 Apr 2004 08:57:27 -0400

My point was that ULE allows to put system specific information above the TS layer (as "system independant" hence more end to end). If people use the TS specific information yes we could just ignore or the people who know about it can use it. 

Marie-Jose
  ----- Original Message ----- 
  From: William StanisLaus 
  To: [email-masked] 
  Sent: Tuesday, April 13, 2004 8:18 AM
  Subject: RE: Adaptation field use in ULE / MPG2-TS specification

  Hi Marie-Jose, 
      I understand your point here about extension headers. But actually Adaptation field specified here is part of MPEG2-TS header and not ULE, in that case even ULE is a payload for MPEG2-TS. If adaption field control is 10 or 11 in bits, MPEG2-TS contains private adaption field, and incase of "10" we need not care about anything, but still ULE draft says anything other than " 01" in AFC, receiver MUST discard. 
      Thanks for your comment Tor Brekke, but i wonder why we have such limitation in ULE, even though we are not worried in ULE about the MPEG2-TS private section of Adaption field, if we are not going to take any action based on the adaption field and control field we can just ignore. I see this as an implementation issue and should not be limited in specification/draft.

  transport_packet(){
          sync_byte                                                                                                 8 bslbf
          transport_error_indicator                                                                            1 bslbf
          payload_unit_start_indicator                                                                       1 bslbf
          transport_priority                                                                                       1 bslbf
          PID                                                                                                          13 uimsbf
          transport_scrambling_control                                                                      2 bslbf
          adaptation_field_control                                                                              2 bslbf
          continuity_counter                                                                                     4 uimsbf
          if(adaptation_field_control=='10' || adaptation_field_control=='11'){
                adaptation_field()
          }
          if(adaptation_field_control=='01' || adaptation_field_control=='11') {
               for (i=0;i<N;i++){
                   data_byte                                                                                        8 bslbf
              }
         }
  }

  Also ULE cannot limit anything on exisiting underlying protocol as such MPEG2-TS. But definitly it can limit or provide more services to above layers.

  Best Regards,
  William StanisLaus 

    -----Original Message-----
    From: [email-masked] [mailto:[email-masked]]On Behalf Of Marie-Jose Montpetit
    Sent: Tuesday, April 13, 2004 4:00 PM
    To: [email-masked]
    Subject: Re: Adaptation field use in ULE / MPG2-TS specification

    Marie-Jose

      ----- Original Message ----- 
      From: Tor Brekke 
      To: [email-masked] 
      Sent: Tuesday, April 13, 2004 3:02 AM
      Subject: Adaptation field use in ULE / MPG2-TS specification

      Hello, 

      Best Regards 
      Tor Brekke

---

From: Patrick Cipiere <[email-masked]>
Date: Thu, 15 Apr 2004 21:24:32 +0200

Marie-Jose said
----------
So I do believe we could use ULE in RCS. Actually in a recent study
sponsored by ESA we showed that for traffic with a lot of ACK bursts
(http: for example) ULE was very efficient because of it's packing
capability.
----------

Section packing is not specific to ULE.
It is a feature shared by the mpeg2 layer: thanks to the PUSI bit,
and the section layer: thanks to the embedded length included in the
section header.
It is up to the encapsulator do decide doing or not section packing.
Section packing can be done with any kind of section, and works fine
with MPE.

Patrick.
-- 
UDcast: Full IP over Broadcast Media

Phone:  (+33) (0)4 93 00 16 99
Mobile: (+33) (0)6 14 21 55 98
Fax:    (+33) (0)4 93 00 16 61                 http://www.UDcast.com

---

From: "Marie-Jose Montpetit" <[email-masked]>
Date: Thu, 15 Apr 2004 16:25:00 -0400

We used section packing for MPE since it would have not been fair... However
ULE had not limitations in the number of segments we could pack.

Marie-Jose

---

From: "Marie-Jose Montpetit" <[email-masked]>
Date: Thu, 15 Apr 2004 16:25:00 -0400

Marie-Jose

---

From: Patrick Cipiere <[email-masked]>
Date: Fri, 16 Apr 2004 10:15:30 +0200 (CEST)

----------

Could you explain the segment limitation in MPE?

Thanks,
Patrick.

---

From: Tor Brekke <[email-masked]>
Date: Fri, 16 Apr 2004 10:13:03 +0200

There is no limitations on the number of sectinos in each MPG for MPE 
either. An implementation may of course limit this. 
--Tor

"Marie-Jose Montpetit" <[email-masked]> 
Sent by: [email-masked]
15.04.2004 22:25
Please respond to
[email-masked]

To
<[email-masked]>
cc

Subject
Re: Adaptation field use in ULE / MPG2-TS specification

We used section packing for MPE since it would have not been fair... 
However
ULE had not limitations in the number of segments we could pack.

Marie-Jose

---

From: "William StanisLaus" <[email-masked]>
Date: Fri, 16 Apr 2004 14:42:27 +0530

There is no limitations agreed, But when there is a time slot to push off
your data into the traffic bust, will you be waiting for more sections to
get packed( say you have only one icmp message right now with 64 bytes) or
you just push the section so far you have in hand.

Otherwise, you have some timer for which you wait for sections and push the
traffic into bust.

Though it is more of implemenation, i believe there is no standard, how to
do section packing as such.

Best Regards,
William.

NOTE: all sections are for a particular/single PID.
  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On
Behalf Of Tor Brekke
  Sent: Friday, April 16, 2004 1:43 PM
  To: [email-masked]
  Cc: [email-masked]; [email-masked]
  Subject: Re: Adaptation field use in ULE / MPG2-TS specification

        "Marie-Jose Montpetit" <[email-masked]>
        Sent by: [email-masked]
        15.04.2004 22:25 Please respond to
              [email-masked]

       To <[email-masked]>
              cc
              Subject Re: Adaptation field use in ULE / MPG2-TS
specification

  Marie-Jose

---

From: "Marie-Jose Montpetit" <[email-masked]>
Date: Fri, 16 Apr 2004 06:28:32 -0400

There are just a few things I'd like to mention to take this thread out of the list.

1. On the number of packets: ULE directly gives the packet lenght so it's easy to pack/depack the packets
2. There are some MPE implementations that limit the the number of encapsulated packets to 2 which comes directly from the use of the PUSI (please don't deluge/flame me with "but our company has another one")
3. yes the timer is a big issue and waiting for packing may end up on other impacts at the network layer (time outs, QoS etc.) this has been known for a while in any encapsulation and we did simulation codes in ns2 to vary the timer
4. the goal of the study was not to show MPE (with section packing) was bad and but to show ULE could be used on the return channel, develop ns2 code for ULE and MPE encapsulation and test timers etc.

I would like to end the thread here.

Marie-Jose
  ----- Original Message ----- 
  From: William StanisLaus 
  To: [email-masked] 
  Sent: Friday, April 16, 2004 5:12 AM
  Subject: RE: Adaptation field use in ULE / MPG2-TS specification

  There is no limitations agreed, But when there is a time slot to push off your data into the traffic bust, will you be waiting for more sections to get packed( say you have only one icmp message right now with 64 bytes) or you just push the section so far you have in hand.

  Otherwise, you have some timer for which you wait for sections and push the traffic into bust.

  Though it is more of implemenation, i believe there is no standard, how to do section packing as such.

  Best Regards,
  William.

    -----Original Message-----
    From: [email-masked] [mailto:[email-masked]]On Behalf Of Tor Brekke
    Sent: Friday, April 16, 2004 1:43 PM
    To: [email-masked]
    Cc: [email-masked]; [email-masked]
    Subject: Re: Adaptation field use in ULE / MPG2-TS specification

    There is no limitations on the number of sectinos in each MPG for MPE either. An implementation may of course limit this. 
    --Tor 

         To <[email-masked]>  
                cc  
                Subject Re: Adaptation field use in ULE / MPG2-TS specification 

    Marie-Jose