Subject: Re: [AVT] Review of draft-ietf-avt-rtp-g718-03

From: "Glen Zorn" <[email-masked]>
Date: Wed, 8 Dec 2010 15:23:30 +0700

Qin Wu [mailto:[email-masked]] writes:

Hi,

I have read draft-ietf-avt-rtp-g718-03 and have some editorial comments  as
follows:

Section 2.1:

It is not clear to me the meaning of  "together with L1' , modified L3'
   is used instead of L3" described in section 2.1, do you mean that
enhancement layer 3' depends on L1'?

It means that if L1' is used, L3' is used instead of L3.  Does this change
help?

OLD:

   The G.718 codec also includes an operating mode that is compatible

   with the Adaptive Multi-Rate Wideband (AMR-WB) codec [AMR-WB], for

   which the RTP payload format is specified in [RFC4867].  In this AMR-

   WB interoperable mode, layers L1 and L2 are replaced by L1'

   consisting of AMR-WB encoded data.  Furthermore, together with L1'.

   modified L3' is used instead of L3.  The usage of layers L4 and L5 is

   not affected by transmitting AMR-WB data in the lower layers. 

NEW: 

   The G.718 codec also includes an operating mode that is compatible

   with the Adaptive Multi-Rate Wideband (AMR-WB) codec [AMR-WB], for

   which the RTP payload format is specified in [RFC4867].  In this AMR-

   WB interoperable mode, layers L1 and L2 are replaced by L1'

   consisting of AMR-WB encoded data and L3' is used instead of L3.  The

   usage of layers L4 and L5 is not affected by transmitting AMR-WB data

   in the lower layers. 

Section 2.3:

It will be useful to add a reference to draft-ietf-avt-rtp-svc-24 in the
section 2.3, since draft-ietf-avt-rtp-svc-24 firstly defines

two basic modes for transmission of SVC data, single session transmission
(SST) 

and multi-session transmission (MST).  

True, but it seems to me that the only qualities that the two documents
share are the acronym ;-) - it's not clear to me that what MST means in the
SVC draft is really similar to what is meant in the G.718 draft.

Section 2.4: "Scaling scenarios & rate control"

rephrase the following sentence of section 2.4

"

   3. An intermediate network element passes forward only a subset of
      layers it receives

"

as

"

   3. An intermediate network element passes through only a subset of
      layers it receives

"

OK.

It will be useful in the section 2.4 to add anchor points to section 3.3
"G.718 scaling
" and section 6 "Congestion Control" Since section 2.4 or merge section 2.4,
3.3 and section 6

together, since section 2.4 talks about who do rate control, section 3.3 and
section 6 talks about

which way can be used to perform rate control, i.e., payload thinning or
dropping.

Merging the 3 sections seems reasonable to me; any suggestions for a title?

Section 3.5

It will be useful to explain when G.718 session consist of only one session
and when G.718 session consists of more than one session.

I think the right answer can be found in the section 2.3.

Why do we need to repeat it then? 

Section 3.6

It will be useful to add reference to RFC3550 and RFC6051 since RFC3550
defines sender Report and RFC6051 talks about how to reduce the
synchronisation
 delay for RTP sessions.

Where? 

Section 6 "Congestion Control"

It is not clear what's the difference between payload carrying EDUs and
Transport Block carrying EDUs since 

payload consists of a payload header, followed by one or more transport
blocks?

In this context, I believe that the difference lies in discarding an entire
payload along with all associated EDUs and discarding a subset of the
associated EDUs. 

Are you saying in Multiple Session Transmission mode, some payloads are
dedicated to carry only high layer data EDU?

Don't know.

these payload MUST be discarded?

No.

Regards!

-Qin

---

From: Qin Wu <[email-masked]>
Date: Thu, 09 Dec 2010 15:42:19 +0800

Hi,
  ----- Original Message ----- 
  From: Glen Zorn 
  To: 'Qin Wu' 
  Cc: [email-masked] 
  Sent: Wednesday, December 08, 2010 4:23 PM
  Subject: RE: Review of draft-ietf-avt-rtp-g718-03

  Hi,

  I have read draft-ietf-avt-rtp-g718-03 and have some editorial comments  as follows:

  Section 2.1:

  It is not clear to me the meaning of  "together with L1' , modified L3'
     is used instead of L3" described in section 2.1, do you mean that enhancement layer 3' depends on L1'?

  It means that if L1' is used, L3' is used instead of L3.  Does this change help?

  OLD:

  NEW: 

     in the lower layers. 

  [Qin]: Looks good to me.

  Section 2.3:

  It will be useful to add a reference to draft-ietf-avt-rtp-svc-24 in the section 2.3, since draft-ietf-avt-rtp-svc-24 firstly defines

  two basic modes for transmission of SVC data, single session transmission (SST) 

  True, but it seems to me that the only qualities that the two documents share are the acronym ;-) - it's not clear to me that what MST means in the SVC draft is really similar to what is meant in the G.718 draft.

  [Qin]: I believe they are same.

  "

  "

  as

  "

  "

  OK.

  It will be useful in the section 2.4 to add anchor points to section 3.3 "G.718 scaling
  " and section 6 "Congestion Control"  or merge section 2.4, 3.3 and section 6

  together, since section 2.4 talks about who do rate control, section 3.3 and section 6 talks about

  which way can be used to perform rate control, i.e., payload thinning or dropping.

  Section 3.5

  It will be useful to explain when G.718 session consist of only one session and when G.718 session consists of more than one session.

  [Qin]: Okay. Maybe this section 3.5 is also duplicated and can be removed.

  Section 3.6

  It will be useful to add reference to RFC3550 and RFC6051 since RFC3550 defines sender Report and RFC6051 talks about how to reduce the synchronisation
   delay for RTP sessions.

  Where? 

  [Qin]: Suggest to put a reference RFC6051 behind the first sentence of section 3.6.

  Suggest to put a reference RFC3550 following the last sentence of section 3.6.

  It is not clear what's the difference between payload carrying EDUs and Transport Block carrying EDUs since 

  payload consists of a payload header, followed by one or more transport blocks?

  In this context, I believe that the difference lies in discarding an entire payload along with all associated EDUs and discarding a subset of the associated EDUs. 

  [Qin]: Agree. It is better to rephrase text a little bit to reflect this difference. 

  Are you saying in Multiple Session Transmission mode, some payloads are dedicated to carry only high layer data EDU?

  Don't know.

  [Qin]: We are on the same page. It depends on how EDU is organized in the payload or transport block.

  Discarding an entire payload along with all associated EDUs means discarding all the highest layer EDUs encapsulated in each transport block carried by payload.

  Their difference is

  one is discarding one transport block containing highest layer data while the other is discarding all the transport block containing highest layer EDUs.

  Regards!

  -Qin

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 9 Dec 2010 16:22:13 +0700

Qin Wu [mailto://[email-masked]]
<mailto:[mailto://[email-masked]%5d>  writes: 

Section 2.3:

Maybe it's just my ignorance, but I don't see how they are the same outside
of the fact that multiple RTP sessions are used to transport data:  

1.   SVC is video data, but G.718 is an audio codec

2.   draft-ietf-avt-rtp-svc-24 defines 4 modes of MST, differing in "whether
or not they allow interleaving,   i.e., transmitting Network Abstraction
Layer (NAL) units in an order  different than the decoding order, and by the
technique used to  effect inter-session NAL unit decoding order recovery",
but I believe that the NAL construct  is specific to H.264

Given these differences, it seems more confusing than enlightening to insert
a reference to draft-ietf-avt-rtp-svc-24, but I'm hardly an expert.

.

Section 3.5

I don't think that it can actually be removed, since it's the only place
where "G.718 session" is defined; maybe move it somewhere else?  As an
aside, it seems like normative and informative  text is kind of all mixed
together; maybe it would be worth some effort to restructure the draft for a
clearer separation?

Section 3.6

Where? 

[Qin]: Suggest to put a reference RFC6051 behind the first sentence of
section 3.6.

Suggest to put a reference RFC3550 following the last sentence of section
3.6.

OK.

[Qin]: Agree. It is better to rephrase text a little bit to reflect this
difference. 

OK, how's this:

   The following means (in no particular order) can be used to assist

   congestion control procedures -- either by the sender or by the

   intermediate node.

   o  The payloads carrying the EDUs representing the highest layers in

      an G.718 session can be dropped, along with all associated

      transport blocks

   o  The transport blocks carrying the EDUs representing the highest

      layers within the payload can be dropped

   o  Transport blocks or payloads carrying EDUs belonging to redundant

      frames included in the payload can be dropped

Don't know.

[Qin]: We are on the same page. It depends on how EDU is organized in the
payload or transport block.

Discarding an entire payload along with all associated EDUs means discarding
all the highest layer EDUs encapsulated in each transport block carried by
payload.

Their difference is

one is discarding one transport block containing highest layer data while
the other is discarding all the transport block containing highest layer
EDUs.

Regards!

-Qin

---

From: Qin Wu <[email-masked]>
Date: Fri, 10 Dec 2010 15:34:37 +0800

Hi,
  ----- Original Message ----- 
  From: Glen Zorn 
  To: 'Qin Wu' 
  Cc: [email-masked] 
  Sent: Thursday, December 09, 2010 5:22 PM
  Subject: RE: Review of draft-ietf-avt-rtp-g718-03

    Qin Wu [mailto://[email-masked]] writes: 

    Section 2.3:

    Maybe it's just my ignorance, but I don't see how they are the same outside of the fact that multiple RTP sessions are used to transport data:  

    2.   draft-ietf-avt-rtp-svc-24 defines 4 modes of MST, differing in "whether or not they allow interleaving,   i.e., transmitting Network Abstraction Layer (NAL) units in an order  different than the decoding order, and by the technique used to  effect inter-session NAL unit decoding order recovery", but I believe that the NAL construct  is specific to H.264

    Given these differences, it seems more confusing than enlightening to insert a reference to draft-ietf-avt-rtp-svc-24, but I'm hardly an expert.

    .

    [Qin]: Sounds reasonable to me. maybe draft-ietf-avt-rtp-svc-24 should firstly define MST and SST as two generialized acronyms, and then draft-ietf-avt-rtp-g718-03 can refer to such acronym in the draft-ietf-avt-rtp-svc-24.

    Section 3.5

    I don't think that it can actually be removed, since it's the only place where "G.718 session" is defined; maybe move it somewhere else?  As an aside, it seems like normative and informative  text is kind of all mixed together; maybe it would be worth some effort to restructure the draft for a clearer separation?

    [Qin]: Okay.

    Section 3.6

    Where? 

    OK.

    OK, how's this:

       intermediate node.

          transport blocks

    [Qin]: It is much better than the original text.

    Don't know.

    Their difference is

    Regards!

    -Qin