Subject: [AVT] Comments on draft-ietf-avt-rapid-acquisition-for-rtp-05

From: Eric Friedrich <[email-masked]>
Date: Tue, 8 Dec 2009 11:42:14 -0500

Below are comments on draft-ietf-avt-rapid-acquisition-for-rtp-05.  
They are mostly minor with some suggested improvements in signaling to  
resolve alignment issues. However, there are several interoperability  
concerns coming from Section 6.2 and 6.3.

Section 6.2, Step 2
1)  One of the RAMS goals is to quickly fall back to a simple (non- 
rapid) multicast join if RAMS is not accepted/not possible/fails due  
to packet loss. Meeting this goal requires a short time frame for RAMS- 
I reception. The document today is unclear on the timing of RAMS-I in  
such cases.

The statement "RS MAY send the RAMS-I message after a significant  
delay, so RTP_Rx SHOULD NOT make protocol dependencies on quickly  
receiving an RAMS-I message." contradicts a later statement in Section  
6.4 that states the RTP_Rx MAY time out based on previous observed  
response times. Further, the recommendation that the RAMS-I be sent  
early enough to be useful is not clear because the meaning of "useful"  
is not known or defined here. One goal of Rapid Synchronization is  
maintaining the ability to quickly fall back to a non-rapid multicast  
join. This is not possible if the RAMS-I message may arrive some time  
(seconds) later after the RAMS-R was sent.

We suggest that the RAMS-I should be sent at the same that the unicast  
burst begins, containing at a minimum the first unicast sequence  
number. The RAMS-I can later be updated with other parameters as  
needed by sending additional RAMS-I packets.

2) The criteria that the RS SHOULD or MUST use for deciding whether to  
accept or reject the request should be stated.  In particular, the RS  
MUST (or at minimum SHOULD) conform to the requested burst rate and  
minimum and maximum sizes if these are provided by the client.   
Failure to do this will result in interoperability problems.

Section 6.2, Step 3
How will differing implementations operate with each other if one RS  
implementation sends additional data in a format such as  [I-D.begen- 
avt-rtp-mpeg2ts-preamble], but the RTP_Rx does not conform to or honor  
that format? Suggest requiring support for application-specific  
preamble formats to ensure interoperability when needed by the content.

Section 6.2, Step 6
If the RTP Rx is going to issue retransmission requests SHOULD it, or  
MUST it wait until after the unicast burst has completed before doing  
so?   If it does not wait, SHOULD or MUST the RS wait until the  
unicast burst has completed before sending the requested  
retransmissions? We suggest that the RS MUST wait until the unicast  
burst has completed before sending retransmissions. Also, the RTP_Rx  
SHOULD wait until the unicast burst has ended before requesting  
retransmissions.

Section 6.3
1)  "The bursting rate may be determined by taking into account the  
following data, when available:"
   This may would be better as an normative MAY, unless the use of  
each piece of information below (a-f) is also specified in more detail.
2) "During this time frame, RTP_Rx will join the primary multicast  
session because it was instructed to do so via an RAMS-I message or  
based on some heuristics."
   From earlier in the document, my understanding is that the RTP_Rx  
must adhere to the IGMP join time provided in RAMS-I. The earlier  
sections should contain a mention of a heuristic if that is also a  
valid option. Also, Is this statement intended to be a requirement, or  
a statement that the other requirements in the document will make this  
true?  If not, then maybe this could be stated as "typically" rather  
than as simply a fact.

Section 6.4
Document appears to be missing discussion of packet loss on unicast  
stream, especially the "first seq #" which was described as important  
in Section 6.2.

Section 7.1
Value field should begin on 32-bit word boundary. 16 bit field should  
be on even byte boundaries. We suggest adding an 8 bit reserved field  
between the Type and Length fields. This applies to both vendor  
neutral and private extensions. The semantics of the length field  
should be updated to exclude the new reserved field.

Section 7.2&7.4
  To maintain proper word alignment, each TLV element should begin at  
bit 0 of a word. We suggest adding a 24 bit reserved field to pad the  
first word of both the RAMS-R and RAMS-T messages.

Section 7.2
Max Receive Bitrate - Is 32 bits for this field enough? That will  
limit the max bitrate of a RAMS burst to ~4Gbps. Consider specifying  
in kbps (or alternately moving to a 64-bit field).

Section 9
The NAT considerations don't seem to be complete. Is it possible to  
defer completing this section to a separate document with a more  
thorough treatment? Perhaps this session should informatively  
reference a future solution such as http://tools.ietf.org/html/draft-begen-avt-ports-for-ucast-mcast-rtp-01

Section 10
  The reason for including this section is not clear and I don't  
believe it serves any useful purpose in this draft. Suggest removing  
Section 10 entirely.

Thank You,
Eric Friedrich

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 8 Dec 2009 17:47:13 -0800

Hi Eric,

Thanks for the detailed comments. I will put in my own comments and ask WG to provide further comments. Then, we should address these comments in the next revision.

> -----Original Message-----
> From: Eric Friedrich (efriedri)
> Sent: Tuesday, December 08, 2009 11:42 AM
> To: [email-masked]
> Cc: Ali C. Begen (abegen)
> Subject: Comments on draft-ietf-avt-rapid-acquisition-for-rtp-05
> 

I believe this is a good suggestion. It will bring more consistency as well. One thing we need to take care of is including a sender report with the RAMS-I messages. This is currently recommended in the draft. We just need to make an additional note that if the first RAMS-I is sent before the burst, there can't be a sender report in the same RTCP packet. 
 
> Failure to do this will result in interoperability problems.

Agree. RS SHOULD conform to any requests specified in the RAMS-R message. If it cannot provide the requested burst, it SHOULD reject the request.
 
> preamble formats to ensure interoperability when needed by the content.

As much as we would like to keep RAMS payload independent, certain rules may be required for interoperability. I agree with this. The receiver may indicate its support/desire to get such messages from the server in the RAMS-R message. But, I am not sure how useful it will be since the whole architecture in the server may be relying on sending the payload-specific information. 

I'd like to get WG's input on this.

> SHOULD wait until the unicast burst has ended before requesting

The current draft does not say much about this. If there are strong reasons for doing it this way or in another way, we should provide them in the text. If the receiver waits until the burst is over, RS will not be transmitting any retransmission of the burst packets before the burst is over anyway. But, why should we delay the retransmission request(s)?

I guess if ret packets interrupt the transmission of the burst packets by a margin, pre-computed join times, etc. may become incorrect. This needs to be worded carefully.

Any proposed wording?
 
> each piece of information below (a-f) is also specified in more detail.

This section is rather informative but I am fine with MAY.

> must adhere to the IGMP join time provided in RAMS-I. The earlier

Actually, we are not that clear on this front either. I suggest the draft mandates the receiver to adhere to the join time provided by the server (when available). Any objections?

> true?  If not, then maybe this could be stated as "typically" rather

So, I suggest that the receiver uses "heuristics" if no information from the server is available. If information is available, the receiver must pay attention to it.

> stream, especially the "first seq #" which was described as important

I will need clarification on this. If the 1st burst packet is lost, it can be recovered by retransmission based on the guidelines we will provide (see above). If retransmission is not an option, I guess the burst might become useless as most of the cases the first packet will have important information in it.
 
> should be updated to exclude the new reserved field.

Sounds like a good idea. Wasting an 8-bit field for this is a good trade-off.
 
> first word of both the RAMS-R and RAMS-T messages.

Yeah, I guess this is what we have to do due to the SFMT field we introduced. If WG does not like this idea, we can go back to the option of using FMT values. Either is fine with me.
 
> in kbps (or alternately moving to a 64-bit field).

Either is fine. Any comments on this?
 
> reference a future solution such as http://tools.ietf.org/html/draft-begen-avt-ports-for-

This is what we intend to do. 
 
> believe it serves any useful purpose in this draft. Suggest removing

That section was useful during the development of this draft. But, I agree we can drop it at this stage.

-acbegen

---

From: Zou ZiXuan <[email-masked]>
Date: Wed, 09 Dec 2009 13:42:52 +0800

Hi, All
> Actually, we are not that clear on this front either. I suggest the draft
> mandates the receiver to adhere to the join time provided by the server
(when
> available). Any objections?

I agree that heuristic is a valid option. During the unicast burst when the
burst rate is changed, further RAMS-I message may be sent for updating the
IGMP join time but may get lost or even the update may not be sent, in this
case heuristic can help reduce or eliminate the adverse effect of the
absence of these RAMS-I messages. So it would be more save if RP_Rx has
option on which way it prefer.
> So, I suggest that the receiver uses "heuristics" if no information from
the
> server is available. If information is available, the receiver must pay
attention
> to it.
If no information from the server is available, here comes a question, how
is a receiver supposed to do "heuristic"? 

ZiXuan Zou, Senior Research Staff
Media Technology Research Department
HUAWEI TECHNOLOGIES CO.,LTD. 

Address: Huawei Industrial Base
Bantian Longgang
Shenzhen 518129, P.R.China
Tel: +86 0755 28789364
Fax: +86 0755 28788317
E-mail: [email-masked]
www.huawei.com
----------------------------------------------------------------------------
---------------------------------------------------------
This e-mail and its attachments contain confidential information from
HUAWEI, which 
is intended only for the person or entity whose address is listed above. Any
use of the 
information contained herein in any way (including, but not limited to,
total or partial 
disclosure, reproduction, or dissemination) by persons other than the
intended 
recipient(s) is prohibited. If you receive this e-mail in error, please
notify the sender by 
phone or email immediately and delete it!

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Ali
C.
> Begen (abegen)
> Sent: Wednesday, December 09, 2009 9:47 AM
> To: Eric Friedrich (efriedri); [email-masked]
> Subject: Re: [AVT] Comments on draft-ietf-avt-rapid-acquisition-for-rtp-05
> 
> Hi Eric,
> 
> Thanks for the detailed comments. I will put in my own comments and ask WG
> to provide further comments. Then, we should address these comments in the
> next revision.
> 
> I believe this is a good suggestion. It will bring more consistency as
well. One
> thing we need to take care of is including a sender report with the RAMS-I
> messages. This is currently recommended in the draft. We just need to make
> an additional note that if the first RAMS-I is sent before the burst,
there can't
> be a sender report in the same RTCP packet.
> 
> Agree. RS SHOULD conform to any requests specified in the RAMS-R message.
> If it cannot provide the requested burst, it SHOULD reject the request.
> 
> > Section 6.2, Step 3
> As much as we would like to keep RAMS payload independent, certain rules
> may be required for interoperability. I agree with this. The receiver may
> indicate its support/desire to get such messages from the server in the
> RAMS-R message. But, I am not sure how useful it will be since the whole
> architecture in the server may be relying on sending the payload-specific
> information.
> 
> The current draft does not say much about this. If there are strong
reasons for
> doing it this way or in another way, we should provide them in the text.
If the
> receiver waits until the burst is over, RS will not be transmitting any
> retransmission of the burst packets before the burst is over anyway. But,
why
> should we delay the retransmission request(s)?
> 
> I guess if ret packets interrupt the transmission of the burst packets by
a
> margin, pre-computed join times, etc. may become incorrect. This needs to
be
> worded carefully.
> Actually, we are not that clear on this front either. I suggest the draft
> mandates the receiver to adhere to the join time provided by the server
(when
> available). Any objections?
> 
> So, I suggest that the receiver uses "heuristics" if no information from
the
> server is available. If information is available, the receiver must pay
attention
> to it.
> I will need clarification on this. If the 1st burst packet is lost, it can
be
> recovered by retransmission based on the guidelines we will provide (see
> above). If retransmission is not an option, I guess the burst might become
> useless as most of the cases the first packet will have important
information in
> it.
> Yeah, I guess this is what we have to do due to the SFMT field we
introduced. If
> WG does not like this idea, we can go back to the option of using FMT
values.
> Either is fine with me.
> > reference a future solution such as
> http://tools.ietf.org/html/draft-begen-avt-ports-for-
> > ucast-mcast-rtp-01
> 
> That section was useful during the development of this draft. But, I agree
we
> can drop it at this stage.
> 
> -acbegen
> 
> >
> > Thank You,
> > Eric Friedrich
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: Eric Friedrich <[email-masked]>
Date: Wed, 9 Dec 2009 09:41:50 -0500

Zou-
  All good comments. Thank You.
> option on which way it prefer.

The heuristic should only be used when the RS does not provide a join  
time in a RAMS-I message. Anytime the server does provide the join  
time, it is the responsibility of the client to honor that. I do not  
believe we should be concerned with loss of the RAMS-I here because  
you are allowed to send multiple copies of the same RAMS-I. I  
understand that there are cases where the RTP_Rx may not be interested  
a server designated join time. However, ignoring the join time from  
the RS can lead to undesirable results such as buffer overflows in the  
RTP_Rx or packet loss.

> is a receiver supposed to do "heuristic"?

The description of such a heuristic is likely implementation specific  
and probably does not belong in the draft. The use of such a heuristic  
is purely optional, you don't need to use one to have a functioning  
implementation.

Thank You,
Eric Friedrich

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 9 Dec 2009 07:40:56 -0800

One more comment on the heuristics on the receiver side:

If the first RAMS-I message is lost, but the burst starts arriving, RAMS will not typically be useful at all (See sec 6.4). However, if another (updated) RAMS-I is sent for some reason and received early enough in the process, the receiver may still pull it off. Ow, it has to give up. Plain and simple. W/o any RAMS-I, the receiver is in the dark. The question is when it times out and sends a join message.

However, if a RAMS-I is received by the receiver but then the server makes changes in the burst and sends a new RAMS-I but that updated RAMS-I is not received, now this scenario is a good fit for some sort of receiver-based heuristics. Because, the receiver knows the initial RAMS-I message content and observed the change in the burst (e.g., bitrate, etc.), now it *can* make an educated guess about the updated join time, if it wants to.

That is all what is for the heuristics IMO. 

OTOH, I suggest we make the text more clear. If information from the server is available, the receiver SHOULD adhere to it.

How does the receiver know whether it has received the latest RAMS-I from the server? It cannot. But, unless it strongly believes that it is missing something, it should adhere to the latest information (That's why I suggest we use SHOULD rather than MUST).

-acbegen 

> Sent: Wednesday, December 09, 2009 9:42 AM
> To: Zou ZiXuan
> Cc: Ali C. Begen (abegen); [email-masked]

---

From: Zou ZiXuan <[email-masked]>
Date: Thu, 10 Dec 2009 15:59:28 +0800

Hi, All
> However, if a RAMS-I is received by the receiver but then the server makes
> changes in the burst and sends a new RAMS-I but that updated RAMS-I is not
> received, now this scenario is a good fit for some sort of receiver-based
> heuristics. Because, the receiver knows the initial RAMS-I message content
and
> observed the change in the burst (e.g., bitrate, etc.), now it *can* make
an
> educated guess about the updated join time, if it wants to.
> 
IMO the Server can deduce the IGMP join time because it has adequate
information besides burst rate to do so, like the information related to
ongoing multicast flow and related to the multicast flow at the time when a
RAMS-R is received. Without the information of these sorts, I'm not quite
clear on how a receiver could "guess" a updated join time.

If heuristic is considered a valid option, it is worthy of more description
with greater details IMO.

Cheers,

> From: Ali C. Begen (abegen) [mailto:[email-masked]]
> Sent: Wednesday, December 09, 2009 11:41 PM
> To: Eric Friedrich (efriedri); Zou ZiXuan
> Cc: [email-masked]
> Subject: RE: [AVT] Comments on draft-ietf-avt-rapid-acquisition-for-rtp-05
> 
> If the first RAMS-I message is lost, but the burst starts arriving, RAMS
will not
> typically be useful at all (See sec 6.4). However, if another (updated)
RAMS-I is
> sent for some reason and received early enough in the process, the
receiver
> may still pull it off. Ow, it has to give up. Plain and simple. W/o any
RAMS-I, the
> receiver is in the dark. The question is when it times out and sends a
join
> message.
> 
> However, if a RAMS-I is received by the receiver but then the server makes
> changes in the burst and sends a new RAMS-I but that updated RAMS-I is not
> received, now this scenario is a good fit for some sort of receiver-based
> heuristics. Because, the receiver knows the initial RAMS-I message content
and
> observed the change in the burst (e.g., bitrate, etc.), now it *can* make
an
> educated guess about the updated join time, if it wants to.
> 
> OTOH, I suggest we make the text more clear. If information from the
server is
> available, the receiver SHOULD adhere to it.
> 
> How does the receiver know whether it has received the latest RAMS-I from
the
> server? It cannot. But, unless it strongly believes that it is missing
something, it
> should adhere to the latest information (That's why I suggest we use
SHOULD
> rather than MUST).
> > Subject: Re: [AVT] Comments on
draft-ietf-avt-rapid-acquisition-for-rtp-05

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 10 Dec 2009 07:37:25 -0800

> From: Zou ZiXuan [mailto:[email-masked]]
> Sent: Thursday, December 10, 2009 2:59 AM
> To: Ali C. Begen (abegen); Eric Friedrich (efriedri)
> Cc: [email-masked]

Exactly, server knows the lag between the burst and multicast.

> clear on how a receiver could "guess" a updated join time.

If no RAMS-I was ever received, as I said earlier, receiver will have no idea. If an older RAMS-I was available but then the burst parameters have changed, the receiver may compute something potentially useful.

> with greater details IMO.

I don't think we need to worry about this too much and if nobody has a good text for it (e.g. the steps the receiver should follow), I suggest we remove that part from the document.

-acbegen

---

From: Zou ZiXuan <[email-masked]>
Date: Fri, 11 Dec 2009 09:14:01 +0800

Hi, Ali, Eric and All
	Inline. 
Cheers
> Sent: Thursday, December 10, 2009 11:37 PM
> To: Zou ZiXuan; Eric Friedrich (efriedri)
> Cc: [email-masked]
> > Subject: RE: [AVT] Comments on
> Exactly, server knows the lag between the burst and multicast.
So if the server gives this parameter to the client, it would be more
convenient for the client to heuristically update its IGMP join time.

> If no RAMS-I was ever received, as I said earlier, receiver will have no
idea. If an
> older RAMS-I was available but then the burst parameters have changed, the
> receiver may compute something potentially useful.
> 
> I don't think we need to worry about this too much and if nobody has a
good
> text for it (e.g. the steps the receiver should follow), I suggest we
remove that
> part from the document.
We have submitted a updated draft on heuristic solution regarding the "lag
between the burst and multicast" (i.e. named backspace field in our draft)
as well as the example of how this parameter be used for heuristic.

Your comments are welcome.
http://tools.ietf.org/id/draft-zou-avt-new-tlv-element-rams-00.txt

---

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Fri, 11 Dec 2009 09:38:40 +0100

Some additional comments (look for :TOM) 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ali C. Begen (abegen)
Sent: woensdag 9 december 2009 2:47
To: Eric Friedrich (efriedri); [email-masked]
Subject: Re: [AVT] Comments on
draft-ietf-avt-rapid-acquisition-for-rtp-05

Hi Eric,

Thanks for the detailed comments. I will put in my own comments and ask
WG to provide further comments. Then, we should address these comments
in the next revision.

> to packet loss. Meeting this goal requires a short time frame for 
> RAMS- I reception. The document today is unclear on the timing of 
> RAMS-I in such cases.
> 

I believe this is a good suggestion. It will bring more consistency as
well. One thing we need to take care of is including a sender report
with the RAMS-I messages. This is currently recommended in the draft. We
just need to make an additional note that if the first RAMS-I is sent
before the burst, there can't be a sender report in the same RTCP
packet. 

TOM: I have a different opinion here.. If the RTP receiver starts
receiving RTP burst packets without an initial accompanying RAMS_I
message, then the quick fall back is still possible without requiring
that a RAMS-I is sent as early as possible. We may indeed explain what
"useful" means here, but I see no need that a RAMS-I message always
needs to precede the RTP burst packets, and hence the RAMS-I can be
"delayed". 

> Failure to do this will result in interoperability problems.

Agree. RS SHOULD conform to any requests specified in the RAMS-R
message. If it cannot provide the requested burst, it SHOULD reject the
request.

As much as we would like to keep RAMS payload independent, certain rules
may be required for interoperability. I agree with this. The receiver
may indicate its support/desire to get such messages from the server in
the RAMS-R message. But, I am not sure how useful it will be since the
whole architecture in the server may be relying on sending the
payload-specific information. 

TOM: I do not see an interop problem here: if the client does not
support it, it will drop the preamble packets.. I agree it would be good
if the client can indicate whether it supports such preamble packets to
make such server solution efficient, but this needs to be covered by the
"preamble" draft  (e.g. by defining a new TLV for the RAMS-R message). 

The current draft does not say much about this. If there are strong
reasons for doing it this way or in another way, we should provide them
in the text. If the receiver waits until the burst is over, RS will not
be transmitting any retransmission of the burst packets before the burst
is over anyway. But, why should we delay the retransmission request(s)?

I guess if ret packets interrupt the transmission of the burst packets
by a margin, pre-computed join times, etc. may become incorrect. This
needs to be worded carefully.

Any proposed wording?

TOM: I strongly disagree that we mandate that a RS shall not send
retransmissions before the unicast burst has ended. As the RS is
controling both the RTP burst and the retransmissions, why would we do
that? If the retransmission process interferes with the burst process in
terms of signaling of burst-related parameters in the RAMS-I message, we
have RAMS-I update messages to signal parameter updates. Similarly, a
RTP receiver can request retransmissions during a unicast burst.

> must adhere to the IGMP join time provided in RAMS-I. The earlier

Actually, we are not that clear on this front either. I suggest the
draft mandates the receiver to adhere to the join time provided by the
server (when available). Any objections?

TOM; I agree

So, I suggest that the receiver uses "heuristics" if no information from
the server is available. If information is available, the receiver must
pay attention to it.

> stream, especially the "first seq #" which was described as important 

I will need clarification on this. If the 1st burst packet is lost, it
can be recovered by retransmission based on the guidelines we will
provide (see above). If retransmission is not an option, I guess the
burst might become useless as most of the cases the first packet will
have important information in it.

TOM: I do not get the comment either. An RTP receiver can always request
retransmissions during a burst based on the OSN field in the burst
packets. It is up to the RS to respond on such a request.

> should be updated to exclude the new reserved field.

Sounds like a good idea. Wasting an 8-bit field for this is a good
trade-off.

Yeah, I guess this is what we have to do due to the SFMT field we
introduced. If WG does not like this idea, we can go back to the option
of using FMT values. Either is fine with me.

 

> believe it serves any useful purpose in this draft. Suggest removing 

That section was useful during the development of this draft. But, I
agree we can drop it at this stage.

-acbegen

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 11 Dec 2009 07:28:38 -0800

Tom,

> From: VAN CAENEGEM Tom [mailto:[email-masked]]
> Sent: Friday, December 11, 2009 3:39 AM
> To: Ali C. Begen (abegen); Eric Friedrich (efriedri); [email-masked]
[snip]
> message, then the quick fall back is still possible without requiring

How? The receiver would not know if it should fall back to regular join w/o first receiving the RAMS-I since it does not know whether it is missing some important packets or not. Without the RAMS-I, the receiver is actually clueless.

> needs to precede the RTP burst packets, and hence the RAMS-I can be

Certain information in RAMS-I is important to describe the burst. So why not send one right at the beginning?
 
> "preamble" draft  (e.g. by defining a new TLV for the RAMS-R message).

RAMS will not break, I agree. But, it may be pretty useless if server's burst depends on the payload-specific stuff but the receiver does not process it. It would be quite useful to decide on some guidelines here IMO.

> RTP receiver can request retransmissions during a unicast burst.

If we wanna keep the ret possibility, we need more specific guidelines. Simply saying the receiver may request retransmission of missing burst packets and the server may provide them, is not sufficient. Would you like to propose new text for this part?

-acbegen

---

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Fri, 11 Dec 2009 17:34:49 +0100

...One more iteration before my weekend starts... 
As usual.. Look for <TOM> in the text below.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ali C. Begen (abegen)
Sent: vrijdag 11 december 2009 16:29
To: VAN CAENEGEM Tom; Eric Friedrich (efriedri); [email-masked]
Subject: Re: [AVT] Comments on
draft-ietf-avt-rapid-acquisition-for-rtp-05

Tom,

[snip]

> > maintaining the ability to quickly fall back to a non-rapid 
> > multicast join. This is not possible if the RAMS-I message may 
> > arrive some time

> with the RAMS-I messages. This is currently recommended in the draft. 
> We just need to make an additional note that if the first RAMS-I is 
> sent before the burst, there can't be a sender report in the same RTCP

> message, then the quick fall back is still possible without requiring

How? The receiver would not know if it should fall back to regular join
w/o first receiving the RAMS-I since it does not know whether it is
missing some important packets or not. Without the RAMS-I, the receiver
is actually clueless.

<TOM> If an RTP receiver receives RTP burst packets before getting a
RAMS-I message, it does obviously already know its RAMS_R request is
serviced by the RS. It does not know yet whether the 1st packet(s)
was/were dropped. But if the RAMS-I has 100 ms delay compared to 1st
burst RTP packet arrival, it would have been not sensible to fall back
to the normal SSM aquisition because the RAMS-I was not received at
least 100 ms earlier, as a minimum set of burst packets are buffered
anyhow by the RTP receiver before their payload proceed to the app
layer. It is up to the RTP receiver implementation how long to wait for
a RAMS-I before leaving the RAMS process and fall back to normal SSM
aquisition. It may decide to not wait for a RAMS-I at all, and start
demuxing/decoding anyhow. We have covered that in the failure case
section. 

> needs to precede the RTP burst packets, and hence the RAMS-I can be 

Certain information in RAMS-I is important to describe the burst. So why
not send one right at the beginning?

<TOM> If the burst is sent ahead of the RAMS-I, only the SN information
in the RAMS-I is immediately meaningful. The other info is optional. 
 
> > accept or reject the request should be stated.  In particular, the 
> > RS MUST (or at minimum SHOULD) conform to the requested burst rate 
> > and minimum and maximum sizes if these are provided by the client.
> message. If it cannot provide the requested burst, it SHOULD reject 
> the request.
> 
> > Section 6.2, Step 3

> > implementation sends additional data in a format such as  
> > [I-D.begen- avt-rtp-mpeg2ts-preamble], but the RTP_Rx does not 
> > conform to or honor
> 
> As much as we would like to keep RAMS payload independent, certain 
> rules may be required for interoperability. I agree with this. The 
> receiver may indicate its support/desire to get such messages from the

> server in the RAMS-R message. But, I am not sure how useful it will be

> since the whole architecture in the server may be relying on sending 
> the payload-specific information.
> 
> support it, it will drop the preamble packets.. I agree it would be 
> good if the client can indicate whether it supports such preamble 
> packets to make such server solution efficient, but this needs to be 
> covered by the "preamble" draft  (e.g. by defining a new TLV for the
RAMS-R message).

RAMS will not break, I agree. But, it may be pretty useless if server's
burst depends on the payload-specific stuff but the receiver does not
process it. It would be quite useful to decide on some guidelines here
IMO.

TOM: I do not see need for guidelines, simply propose a new TLV for the
RAMS-R in the preamble draft.

> > Section 6.2, Step 6
> > If the RTP Rx is going to issue retransmission requests SHOULD it, 
> > or MUST it wait until after the unicast burst has completed before
doing

> reasons for doing it this way or in another way, we should provide 
> them in the text. If the receiver waits until the burst is over, RS 
> will not be transmitting any retransmission of the burst packets 
> before the burst is over anyway. But, why should we delay the
retransmission request(s)?

> that? If the retransmission process interferes with the burst process 
> in terms of signaling of burst-related parameters in the RAMS-I 
> message, we have RAMS-I update messages to signal parameter updates. 
> Similarly, a RTP receiver can request retransmissions during a unicast
burst.

If we wanna keep the ret possibility, we need more specific guidelines.
Simply saying the receiver may request retransmission of missing burst
packets and the server may provide them, is not sufficient. Would you
like to propose new text for this part?

<TOM> OK, I can propose text that is similar to what I described above,
but I do not see reasons to add much more on this topic.  If a RS does
not want to cope with handling simultaneously RTCP NACKs and RAMS-R
messages, it will ignore them. If it does, than it should consider
whether to send a RAMS-I (update) or not. If a RS e.g. operates in a
mode where it sends a RAMS-I with -next to the RTP SN info- only the
"earliest Multicast Join Time" TLV  with value zero -at the moment it
wants the RTP receiver to connect to the SSM-, there is actually nothing
special the RS must do "extra" when supporting retransmissions during a
burst. 

-acbegen

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 11 Dec 2009 08:45:52 -0800

> anyhow by the RTP receiver before their payload proceed to the app

Sure, but now we are voicing a specific number for the lag between the first burst packet and the RAMS-I. See below.

> demuxing/decoding anyhow. We have covered that in the failure case

Sure, but what is wrong with sending a RAMS-I immediately before the burst starts? The advantages overweigh the overhead AFAICT. 
 
> in the RAMS-I is immediately meaningful. The other info is optional.

You mean if the RAMS-I is sent ahead of the burst. And that SN information is very critical. The receiver would definitely wanna know if it is missing some burst packets asap so that it can bail out and join right away. Sending a RAMS-I before the burst starts does not hurt anything, does it?

-acbegen

---

From: Roni Even <[email-masked]>
Date: Thu, 17 Dec 2009 22:13:32 +0200

Inline
Roni Even as Individual

> rules
draft-xia-avt-mpeg2ts-preamble provides a solution that does not require
pre-processing by the RTP_Rx