Subject: Re: [AVT] Comments on draft-begen-avt-rams-scenarios-00

From: Qin Wu <[email-masked]>
Date: Tue, 01 Dec 2009 21:08:38 +0800

----- Original Message ----- 
From: "Ali C. Begen (abegen)" <[email-masked]>
To: "Qin Wu" <[email-masked]>; <[email-masked]>
Sent: Monday, November 30, 2009 11:36 PM
Subject: RE: [AVT] Comments on draft-begen-avt-rams-scenarios-00

Hi Qin,

Snipping out the text we agree so far.

> -----Original Message-----
> From: Qin Wu [mailto:[email-masked]]
> Sent: Monday, November 30, 2009 4:07 AM
> To: Ali C. Begen (abegen); [email-masked]
> Subject: Re: [AVT] Comments on draft-begen-avt-rams-scenarios-00
> 
> Hi, Ali:
> Thank for your clarification. I agree with you identifying all the possible scenarios is
> not our goal.

Good.

> The RTP application. There is a very nice discussion about this in RFC 3550 in case you
> would like to read further.
> 
> [Qin]:It is better to add reference to RFC 3550. I am wondering how to look at
> multiplexing multiplex the RTP and RTCP packets of a session, how it is related to
> "session multiplexing" described in RFC3550?

Multiplexing RTP and RTCP? You mean on a single port? That is a different (mature) draft. 

[Qin]: Are you saying RTP and RTCP share the same port? Which draft do you mention?
 
> >    how ssrc is multiplexed when different multicast RTP streams is transmitted in the
> same
> > RTP session?
> >    where is ssrc multiplexed?
> >    would you like to clarify this?
> 
> If two RTP streams are part of a single RTP session, they need to use different SSRCs and
> the application running this RTP session is said to be doing "ssrc multiplexing."
> 
> [Qin]: Good clarification. I would like to suggest you to add a new section "Definitions"
> to give the definition of "ssrc multiplexing". One more question is:

I believe a simple reference to 3550 is sufficient.

[Qin]: really? "ssrc multiplexing" is new to 3550.

[Qin]: There are no 
> If two RTP streams come from the same media sender, Does it mean they use the same
> multicast address as source address and use different ssrc to distinguish differerent RTP
> streams?

Ha? Do you mean if two RTP streams sent from the same source are using the same (destination) multicast address? Those two streams can be destined to different ports. If so, identification is easy. If they are on the same port, you use SSRC to identify them.

[Qin]: Agree,That is to say,(ssrc,port) pair is enough for differentiating of multiple RTP streams. 
 
> > 4.  Illustrative Scenarios
> >
> > 4.1.  Scenario #1
> >    [Qin]: The title of section 4.1 is not clear to me that what scenario it describes?
> >    May I suggest to change the title into
> >   "
> >   4.1 Scenario #1: Two RTP streams transmitted over different multicast groups
> >   "
> 
> I agree that "scenario #x" does not say much. But, having a two-line title does not makes
> much sense, either.
> 
> [Qin]: I think the title is not too much long as you said.:-)But if you prefer the short
> title for each scenario, maybe the appropriate title for each scenario would be:
> "Scenario #1: Session multiplexing"
> "Scenario #2: SSRC multiplexing(different ssrc + different port)"
> "Scenario #3: SSRC multiplexing(different ssrc + same port)"
> "Scenario #4: Payload-type multiplexing"

Yes, something like this will be better.

[Qin]:Okay.
 
> >    This is the scenario for session multiplexing where RTP streams 1 and
> >    2 are transmitted over different multicast groups.  A practical use
> >    case is where the first and second SSM session carries the primary
> >    video stream and its associated FEC stream, respectively.
> >
> >    We run an individual RAMS session for each RTP stream that we want to
> >    rapidly acquire.  These RAMS sessions MAY run in parallel.
> >
> >    [Qin]: Another case is to run single RAMS session for two RTP streams, e.g.,
> >    video stream and FEC stream,in this case both SSM sessions use the same transport
> >    address for their feedback target or they use the same feedback target.
> >    If it is the case, two RAMS sessions run in prallel is
> >    not the only case for scenario #1, am I right?
> 
> No, if there are two RTP streams, there must be two RAMS sessions. RAMS uses seqnums,
> timestamps, etc. that correspond to each RTP stream individually.
> 
> [Qin]: I agree RAMS should use the same seqnums and timestampes as each RTP stream. But we
> can carry seqnum and timestampe for each RTP stream in one RAMS message, right?

That is not how RAMS works. It does not matter if we define RAMS messages that can carry information regarding multiple streams. At the end, each will have its own unicast burst anyway. So, it is a much better approach IMO to have a separate RAMS session for each RTP stream.

[Qin]:But using one RAMS message to carry information for more than one streams is more efficient IMO than the way you like have.
 
> As I mentioned above, I don't think we should be describing each possible scenario and
> their respective SDPs in detail. It is not clear, either, how much these figures add to
> the discussion already existing in the text. BTW, in the figures, the receiver seems to be
> receiving everything from the retransmission server but as you know only the burst comes
> from the server, and receivers receive the multicast packets directly from the network
> (the packets sent by the media sender or distribution source).
> 
> [Qin]: I agree it is not necessary to numerate all the possible sceanrios. But the purpose
> for numerating all the possible sceanrios is to choose more pratical deployment models.
> Actually you almost have already listed all the practical sceanrios, especially the first
> two scenarios.

And more importantly, one of the main comments in Hiroshima was that we did’t wanna be listing everything since someone could think it was permissible, or a good practice, to implement any of them. Rather, we wanna focus on the models that we think are the most appropriate to deploy.

[Qin]: Maybe it is better to have a comparision analysis for different scenarios in the draft will be useful for us to choose more practical scenarios.

> As regarding to the figures I proposed, what I would like to clarify is
> 1)RTP stream between media sender and Retransimission server is primary multicast RTP
> stream
> 2) RTP stream between Retransmission server and RTP Reciever is unicast RTP stream, i.e.,
> unicast burst.
> Maybe the apppropriate figure you like to see would be:
> "

I appreciate the effort but I still think these figures might be confusing to the reader. It is the ascii text that largely makes these figures more confusing. They also cannot capture every crucial detail we have. I would like to get WG's input on this, too.

[Qin]:Okay,Let's see what other folks think and will it make texts clear.

>                      Multicast RTP Stream
>   |---------------------------------------------------
>   |    +++++++++++++++++++++++++++++++++++++++++++++++|++++
>   |    +           +--------------------+             |   +
>   |    +           |Retransmission      |             |   +
>   |    +           |   Server     Unicast RTP Stream2 |   +
>   |    +           |      ++++++++++++++++++++++++++++|++++
>   |    +           |      +       Unicast RTP Stream1 |   +
>   |    +           |   +--+-------------+-------------+   +
>   |    +           |   |  +             |             |   +
>  +|----+-+         | +----++            |          +--V---V-+
>  | Media |+++++++++> |Burst|      +---+ | RAMS1    |        |
>  |Sender1|   +-----> |Src1 |------|FT1|<---------->|        |
>  |       |---+--+  | +-----+      +---+ |          |        |
>  +-------+   |  |  |                    |          | RTP_Rx |
>  +-------+   |  |  | +-----+      +---+ | RAMS2    |        |
>  | Media |---+  +--> |Burst|------|FT2|<---------->|        |
>  |Sender2|+++++++++> |Src2 |      +---+ |          |        |
>  +-----+-+         | +---+-+            |          +--A--A--+
>   |    +           +---+-+--------------+             |  +
>   |    +               +-+----------------------------|  +
>   |    +                 +++++++++++++++++++++++++++++|+++
>   |    +                                              |  +
>   |    +++++++++++++++++++++++++++++++++++++++++++++++|+++
>   |---------------------------------------------------|
> -----> RTP Stream 1
> +++++> RTP Stream 2
>                     Figure 1: Session Multiplexing
> "
> But scenario 1 described in section 4.1 is still one complicated scenario and needs to be
> further broken down.
> because
> 1)two RTP streams coming from different media senders may use the same transport address
> for their feedback targets or use the different transport address for each feedback
> target;
> when two RTP streams use the same transport address for their feedback target, they should
> use different ssrc.
> when two RTP streams use the different transport addresses for each feedback target, they
> may use the same ssrc.

This is already discussed in the section related to FT issues. But, I expect we will be sticking to only one of them as there was a rough consensus in the last meeting that it was almost impossible to control what SSRCs the sources would assign to their streams. So, it does not make sense to announce the SSRCs in the SDP, either, in large deployments. To avoid any ambiguity, a unique FTAp will be needed for each RTP stream.

This should be rather fixed in the RAMS draft.

[Qin]: Are you saying ssrc should be transparent to the RTP recievers or Retransmission server? I think we should be
careful to make conclusion too early. Because RAMS draft only considers one RTP stream for one RTP recievers. (SSRC+Port)pairs is important aspect to distinguish more than one RTP streams for one RTP recievers. I don't think we should fix this in the RAMS draft.

> 2) Also two RTP streams transimitted via different multicast group may come from the same
> media sender or may come from two different media sender,
> if 1) and 2) are true, the figure 1 corresponding to scenario 1 can be further divided
> into the following sub-scenarios:
> 
>                      Multicast RTP Stream 1
>      |-------------------------------------------------|
>      |             +--------------------+              |
>      |             |Retransmission      |              |
>      |Multicast RTP|   Server           |              |
>  +---|---+ Stream1 | +-----+      Unicast RTP Stream1  |
>  | Media |---------->|Burst|------------+--------------+
>  |Sender1|         | |Src1 |     +-----+|  RAMS1   +---V----+
>  +-------+         | +-----+     | FT1 |<--------->|        |
>                    |             +-----+           | RTP_Rx |
>  +----Multicast RTP|             +-----+|  RAMS2   |        |
>  | Media |Stream2  | +-----+     | FT2 |<--------->|        |
>  |Sender2|---------->|Burst|     +-----+           +---A----+
>  +---|---+         | |Src2 +------------+--------------+
>      |             | +-----+     Unicast RTP Stream2   |
>      |             +--------------------+              |
>      |-------------------------------------------------|
>                     Multicast RTP Stream 2
>                   Figure a: Session Multiplexing 1.1
> 
> 
>                     Multicast RTP Stream 1
>     |-------------------------------------------------|
>     |             +--------------------+              |
>     |             |Retransmission      |              |
>     |Multicast RTP|   Server           |              |
> +---|---+ Stream1 | +-----+      Unicast RTP Stream1  |
> | Media |---------->|Burst|------------+--------------+
> |Sender1|         | |Src1 |      +----+|          +---V----+
> +-------+         | +-----+      |    ||  RAMS    |        |
>                   |              |FT  |<--------->| RTP_Rx |
> +----Multicast RTP|              |    ||          |        |
> | Media |Stream2  | +-----+      +----+|          |        |
> |Sender2|---------->|Burst|            |          +---A----+
> +---|---+         | |Src2 +------------+--------------+
>     |             | +-----+     Unicast RTP Stream2   |
>     |             +--------------------+              |
>     |-------------------------------------------------|
>                    Multicast RTP Stream 2
>                  Figure b: Session Multiplexing 1.2
> 
> 
>                      Multicast RTP Stream 1
>      |-------------------------------------------------|
>      |             +--------------------+              |
>      |             |Retransmission      |              |
>      |             |   Server           |              |
>      |   Multicast | +-----+      Unicast RTP Stream1  |
>      |  RTP Stream1| |Burst|------------+--------------+
> +----+--+    |------>|Src1 |      +----+|          +---V----+
> |       |    |     | +-----+      |    ||  RAMS    |        |
> | Media +----+     |              |FT  |<--------->| RTP_Rx |
> |Sender |    |     |              |    ||          |        |
> |       |    |     | +-----+      +----+|          |        |
> +----+--+    |------>|Burst|            |          +---A----+
>      |   Multicast | |Src2 +------------+--------------+
>      |  RTP Stream2| +-----+     Unicast RTP Stream2   |
>      |             +--------------------+              |
>      |-------------------------------------------------|
>                     Multicast RTP Stream 2
>                   Figure c: Session Multiplexing 1.3
> 
> 
>                      Multicast RTP Stream 1
>      |-------------------------------------------------|
>      |             +--------------------+              |
>      |             |Retransmission      |              |
>      |   Multicast |   Server           |              |
>      |  RTP Stream1| +-----+      Unicast RTP Stream1  |
> +----+--+    |------>|     |------------+--------------+
> |       |    |     | |     |     +-----+|  RAMS1   +---V----+
> | Media +----+     | |     |     | FT1 |<--------->|        |
> |Sender |    |     | |Burst|     +-----+           | RTP_Rx |
> |       |    |     | |Src  |     +-----+|  RAMS2   |        |
> +----+--+    |------>|     |     | FT2 |<--------->|        |
>      |   Multicast | |     |     +-----+           +---A----+
>      |  RTP Stream2| |     |------------+--------------+
>      |             | +-----+     Unicast RTP Stream2   |
>      |             +--------------------+              |
>      |-------------------------------------------------|
>                     Multicast RTP Stream 2
>                   Figure d: Session Multiplexing 1.4
> 
> "
> I am wondering in the Figure a,b,c,d, which of them are practical scenarios?
> I don't think the scenario described in the figure d mentioned above is a pratical
> scenario. Because normally two RTP streams should have the different ssrc, even they are
> coming from the same media sender, am I right? 

The question is whether they are allowed to or not. And the answer depends on whether they are in the same RTP session or not.

[Qin]: Right.
> 
> As for the scenario described in the figure a is another one-less thing. Because normally
> one Retransmission server only
> assign one transport address for its feedback target, right?

FTAp = IP address + port. So, as ports vary, you will have different FTs.

> > 4.2.  Scenario #2
> >         m=video 40000 RTP/AVP 96
> >         c=IN IP4 233.252.0.1/127
> >         a=rtcp:41001 IN IP4 192.0.2.1
> >         a=ssrc:1 cname:[email-masked]
> >         a=mid:RTP1
> >         m=audio 40001 RTP/AVP 97
> >         c=IN IP4 233.252.0.1/127
> >         a=rtcp:41001 IN IP4 192.0.2.1
> >         a=ssrc:2 cname:[email-masked]
> >         a=mid:RTP2
> >    [Qin]: Not sure the meaning of "a=mid", suggest to provide reference for SDP sematics
> > for "a=mid:"?
> 
> Do you mean RFC 4566, the current SDP spec?
> 
> [Qin]: No, I mean RFC3388.In other words, RFC3388 should be referenced for "a=mid".

Yeah, it is in 3388. There is a bis draft that completed WGLC, so 3388 will be obsoleted.

[Qin]: Okay.

> Also audio stream and video should be syncronized, therefore the semantics of "a=group:LS"
> can be used.

Sure, but that is not relevant to this draft.

[Qin]:True.
 
[snip]
-acbegen