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

["Glen Zorn" <[e-mail]>]

Qin Wu [mailto://[e-mail]]
<mailto:[mailto://[e-mail]%5d>  writes: 

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.

 

[Qin]: I believe they are same.

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

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? 

 

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

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

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.

OK.

 

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. 

 

[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

 

 

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