[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] New Version Notification for draft-peilin-avt-rtp-burst-01
On Mar 16, 2009, at 5:47 AM, Zou ZiXuan wrote:
Hi, Ali,
Hi Zou,
Hi, All :)
I'm Zou ZiXuan, Yekui's colleague and the co-editor of peilin's
draft. I'd like to join the discussion on the draft :) See
my comments
as below
The problem is that, if the unwanted burst and the newly
requested
burst are flowing at the same time, congestion will
likely happen,
therefore, handling of such two streams independently does
not seems
very good.
On the other
hand, if the new burst has to start after the
retransmitted BYE is
received or a timeout on the RS has reached, additional
tunning-in
delay is introduced, which is obviously bad for the
whole purose.
You send the BYE, and then an RMS-R for the new stream.
Unless BYE gets lost or is processed later the RMS-R, the
new burst
will not collide with the old burst.
The FTs for the current stream and the new stream might be
different. But, what you are saying below assumes they are all on
the same FT address/port.
-acbegen
Before talking about different FTs, I'll draw attention from this
complexity back to some points for a while that I think should be
clarified at the first
place:
1) There is semantic confusion among RMS-T and BYE in
the draft,
which I think should be further clairfied: RMS-T is used
for ceasing
the unicast burst with its seq field being empty when RR
only receive
unicast burst during fast sync. BYE is also
The seqnum field in the RMS-T may or may not be filled
depending on whether RR has already received the first packet or not.
mandated to do the SAME THING in case of unicast burst and
multicast
stream co-existing if RR are no long interested in the current
channel. So why not use RMS-T for both of these cases for
achieving
the same purpose, otherwise it would be very confused.
BYE (on the retransmission/burst session) ends the unicast
RTP session. RMS-T ends (or intends to end) the burst, not
the session. The session stays available for (potential)
outstanding retransmissions.
ZX: BYE is a measure for ending the unicast RTP session, but may not
be
mandatory.
Here is an example of ending the current session and starting a new on
in the channel change context without using BYE message, as follows:
1, Every channel has a SDP which includes the descriptions of
Sessions for e.g. unicast and retransmission, such as:
m=video 40000 RTP/AVPF 96
i=Primary Source Stream #1
..
m=video 40002 RTP/AVPF 97
i=Unicast Retransmission Stream #1
..
2, a) When RR and RS start up (or power on), RS creates all the
sessions involved in SDP
What if there is a lineup with 5000 channels? This seems highly
unrealistic for state consumption on the RR, not to mention the
potential problems with holding a session open on a multicast group
you have not joined. What use is such state?
b) RR creates session using SDP and sends RMS-R;
c) Upon receiving RMS-R, RS creates or updates the
state of relevant sessions and issue RMS-I and burst.
d) When RR changes channel again, it selects the SDP for
the new channel, deletes the previous session, creates the new session
and sends RMS-R:
Uh, I don't think that works. You can't just "delete the previous
session" if it's the retransmission session because that leaves state
hanging on the RS. You do really need to send a BYE to the RS so it
knows when to clean up; otherwise it will keep sending you sender
reports, if nothing else. If you're talking about the multicast
session, it's still a good idea to send a BYE in order for the SSM DS
to keep approximate track of the number of receivers for RTCP timer
tuning and other functions.
e) Upon receiving the new RMS-R, RS updates the state of
relevant sessions according to RR's SSRC, ceases the previous burst as
well as retransmission and start a new sync process.
I think you are still missing the fact that it can't do this, because
the RS for one channel may be a totally different box from the RS for
another channel.
As you mentioned before, this is the example of same FT for the
previous and the new channel. In different FTs case, BYE can be used
for
RR indicating its leaving the old FT.
But how do you know? Even the same FT address for two channels could
be different boxes.
2) In the draft, BYE message also terminates the current
retransmission session in the second case. This operation may be
redundant, because retransmission operation is only driven by the
request issued by RR - that is, leaving the current
multiast session
naturally drive the current retransmission operation to
terminate. On
If RR leaves the current mcast session, how is RS supposed to
know about this?
RS may know about this by
ZX: ZX: I'm trying to answer this by the example given as above.
Right. I don't think your example works correctly.
the other hand, the retransmission session can be terminated by
out-of-bound measure, for example SDP. So we think using BYE
How? Here, we are following rules of 3550.
ZX: I'm trying to answer this by the example given as above.
message is
not a must in this context.
4) So we suggested that, For semantic clarity in the
draft, a) RMS-T should be used for ceasing the burst in
both cases.
b) BYE message may be not a necesisty.
See the BYE related section of RFC 3550.
Now for Begn's question on different FTs, what we are
proposing below
does assume the streams are all on the same FT
address/port. But this
is one of the possible case of deployment where what we are
proposing
works for the issue of out-of-order or message lose. And In case of
different FTs, upon receiving the RMS-R, the FT for the new
stream can
simply ignore RMS-R's request of ceasing the burst as it is not
provided by the FT. The RMS-T message in this case can be
sent to the
FT for the current stream to stop the burst.
The scheme should allow different FTs for different streams
as well. None of the RTCP messages are reliable and they may
get lost but we do have measures against the loss of such
control messages.
ZX: What measures do we have?
We think giving RMS-R the ability of ceasing the old burst and
retransmission is a measure in case of switching channel under the
same
FT, and as the above example shows, the session can be ended/updated
without using BYE.
But the standard should be specified for the general case, no? It
really doesn't save much if anything by trying to avoid sending the
BYE, does it? Or am I missing some optimization in the single box case
that is a clear win?
FYI, IGMP join/leave messages are not reliable, either. If
"leave" gets lost and the burst starts, it is a similar
problem. I believe we all should do our best in developing
the control plane GIVEN the protocol requirements.
ZX: The issue of leave lost is not a similar problem. RMS-R request
for
"reference information" coming in the first place in burst. So it is
much likely that the reference information get lost so that fast sync
fails, which is supposed to be avoid during sync.
Sorry, I'm not following this. The problem is congesting the channel
due to either multiple multicast flows OR multiple unicast bursts for
different channels going on at the same time, right? So, wheheter the
phenomenon that causes congestion is not terminating an earlier burst
for channel 1 in order to burst for channel 2, or failing to stop a
multicast stream for channel 1 (due to a lost IGMP LEAVE) in order to
join multicast channel 2 the results are the same.
Unlike RMS-R, IGMP
join does not request for "reference information" and thus does not
lead
to the lose of reference information. On the other hand, IGMP join/
leave
never take the bandwidth restriction into account ever since it was
created. But this problem should be considered during fast sync.
I'm sorry - I really can't follow what you're saying here. Could you
try again?
Thanks, DaveO.
-acbegen