Subject: Re: [AVT] Re: I-D ACTION:draft-xu-avt-subrtcp-00.txt

From: Colin Perkins <[email-masked]>
Date: Sun, 11 Feb 2007 18:59:06 +0000

On 2 Feb 2007, at 18:39, Xiaode Xu ((xdxu)) wrote:
> Hi Colin, Thanks for your comments. Please see my points inlined.
> //Xiaode
>
> -----Original Message-----
> From: Colin Perkins [mailto:[email-masked]]
> Sent: Friday, February 02, 2007 12:08 AM
> To: Xiaode Xu (xdxu)
> Cc: [email-masked]; AVT WG
> Subject: Re: [AVT] Re: I-D ACTION:draft-xu-avt-subrtcp-00.txt
>
> On 2 Feb 2007, at 00:30, Xiaode Xu ((xdxu)) wrote:
>> I think I did not catch the points presented in the existing rfc docs
>> (3550 & 3611) correctly in my last email. Thanks for correcting me.
>>
>> But I feel the existing system bears the following issues:
>>
>> - For an 1-way RTP session:  E1-->T1-->T2-->E2, where E and T stands
>> for
>>   Endpoint and Translator.
>>
>>   According to 3550, E1 can send a sender info in SR to E2 which
>> returns
>>   LSR and DLSR to E1. E1 can thus estimate the RTT between E1 and E2.
>> But
>>   E2 does not have a view of the RTT.
>>
>>   With help of 3611, E2 is capable of estimating the RTT with E1 by
>>   exchanging "Receiver Reference Time Report Blocks and DLRR" via the
>> XRs.
>>
>>   In an one speaker only multicast or broadcast session, from the
>>   speaker to any receiver of the session will be an instance of the
>>   such an 1-way rtp session. Another example could be resulted
>>   from some voice mute feature.
>>
>> - According to 3550, a translater can not send sender info i.e. SR.
>> But
>>   assuming T1 can send a XR with time reference report blocks to T1
>> and
>>   receive DLRR from T2 in order to measure RTT between them. So does
>> T2.
>>   In this case, T1 and T2 needs to create their own SSRC and  
>> spread to
>>   E1 and E2 for calculating rtp report interval.
>>
>>   In this case, T1 and T2 are totally confined to the infrastructure.
>> To
>>   have their SSRC in the same SSRC space as that for endpoints E1 and
>> E2
>>   may not be too forceful.
>
> Creating an SSRC is trivial, so I don't see it as a problem.
> [XU]: In order to have all the participants sync up their report
> interval,
>       every ssrc (as rtcp speaker) needs to be maintained by each
> participant,
>       even the effort is just to measure RTT between T1 and T2.
> Creating
>       an SSRC itself is not an issue but its management and sync  
> across
> all
>       participants is not trivial.

So? All participants must implement this code anyway.

>> - How about a rtp sessiong riding over more than two Ts, this can
>> happen
>>   when a call crossing mulitple service providers' network domain.
>>   Meaturing the RTT between any two of the middle boxes based on the
>>   existing 3611 and 3550 protocols could be burdensome.
>
> This is no different for standard RTCP than for your proposal.
> [XU] This is a big difference between SubRTCP and regular RTCP.  
> SubRTCP
>      carrying its own message type, a middle box can immediately  
> forward
>      it further out and simultaneously digest it, if configured to do
> so.
>      This can ensure better accuracy of the RTT estimation. A  
> SubRTCP SR
>      message is capable of soliciting response from all the middle
> boxes,
>      not just one.

I simply do not believe the complexity of looking at RTCP packet  
types is significant compared to checking the subRTCP packet type.

> In order to limit how far a SubRTCP message can reach, a hop limit  
> field may help.

IP has such a field, independent of RTCP or subRTCP.

>      Coming back to the regular RTCP, the intended middle box for its
>      messages is not clear or explicit. Either each middle box parses
>      a received RTCP message to look for the portion of interest to
>      digest or terminate it and create a new RTCP message as a mixer
>      does. If a middle box terminates a received RTCP and creates a
>      new RTCP, the true sender and receiver (listener) will lose the
>      true judgement of the RTP media quality. In principle, I prefer
>      regular RTCP maintains its native observation of its accompanying
>      RTP stream.
>
>      Please think about the advantage of separation of end2end rtcp
>      and internal rtcp for their respective monitoring purpose in
> comparision
>      with one rtcp lumping two things in one participant group. Yes,
>      we can treat all middle boxes as regular RTCP speaker, but the
>      cost and complexity and efficiency in implementation will differ.

I see the complexity as coming from introducing an additional  
protocol where none is needed: subRTCP is more complex than regular  
RTCP.

>> - Also when an RTCP packet traverses through all the middle boxes, if
>>   each box needs to look into a compound RTCP packet for XR packet's
>>   reference time blocks to act, it will delay the passing-through of
>>   the RTCP packet and cause the inaccuracy of the RTT estimation in
>> the
>>   end.
>
> Those boxes have to examine every packet to tell if they are RTCP or
> subRTCP in your proposal. Checking the RTCP packet type values instead
> turns a single "if" statement in the code into a "for" loop containing
> an "if" statement. In almost all cases, that loop will iterate over  
> two
> values (and SR/RR packet, followed by an SDES packet). This adds one
> extra comparison per packet, and will not cause significant delay.
> [XU] The reason being stated above: a middle box only needs to know if
> it's a subRTCP packet or regular RTCP packet. It
>      has its choice whether it needs to dig into a SubRTCP message.
> Regardlessly, it can forward the SubRTCP message
>      further up or down immediately. But for a regular RTCP message, a
> middle box needs to parse the message to know
>      what is being carried to process them accordingly. For  
> example, the
> SDES needs to be made known all the others.
>      SubRTCP can get rid of this burden by simplifying uneccessary
> elements.

As I said previously, who cares? The "burden" of parsing RTCP is  
negligible.

>      On the other hand, per-session observation of an RTP stream at a
> middle box is mostly for debugging purpose. But
>      even so, internal monitoring of a media path may be more  
> important
> than the end2end monitoring from a service
>      provider's purspective.
>      With SubRTCP separation from the regular RTCP, another cent is
> SubRTCP can be turned off when not needed. It should
>      be turned off after the network is tuned well.

This is no different to regular RTCP.

>> Coming back to SubRTCP, it uses its own message type, middle boxes  
>> can
>
>> act upon them right way. Also it is functioning on a different SSRC
>> space which can make the group of endpoints easier in performing
>> regular RTCP jobs.
>
> Why do you think this makes the endpoints job easier? The RTCP packets
> from the infrastructure nodes don't need to reach the end systems, and
> even if they do, I don't see that it will cause any additional
> complexity.
>
> [XU] With endpoints and middle boxes in the same SSRC space, they are
> equal RTCP speaker and should be make known to all
>      participants in order to get the dynamically synced report
> interval.

This has to be done for subRTCP too, if you wish to scale the  
reporting interval. If no, simply send regular RTCP internal to the  
infrastructure.

>> Even Translator can send RR and Mixer can do both SR and RR, they are
>> still not true endpoints.
>> In principle, the true meaningful sense of the RTCP will be more
>> obvious when it accompanys the its RTP session. In field, complaints
>> are usually from RTP endpoints, the true sender and receiver.
>
> I think you misunderstand the definition of RTP session. The  
> association
> of RTP systems that includes the middleboxes and end point is a single
> RTP session, with associated RTCP. RTCP is explicitly intended to  
> allow
> the type of monitoring you desire as part of its "true meaningful
> sense".
>
> [XU] I understood. Treat all RTP nodes involved in one RTP session
> including all endpoints and middle points in one SSRC
>      space is arguable to me. Think about the good aspect of partition
> endpoints and middle nodes into two SSRC-space
>      groups as we do to differ host nodes and transport nodes
> (router/switch) in networking.

What good aspect? It is *intentional* in the design of RTCP that  
middleboxes use the same SSRC space, since it allows endpoints to  
monitor the quality to those middleboxes.

-- 
Colin Perkins
http://csperkins.org/

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: "Xiaode Xu \(xdxu\)" <[email-masked]>
Date: Thu, 15 Feb 2007 11:24:40 -0800

Hi Colin,

Unfortunately the world has too many owners. As a result, a service
provider
does not have visibility to a customer's network, and have no interest
in it,
either. A service provider network is more like a transport at VoIP
plane
with respect to media traffic.

On the other hand, a service provider network would be self-enclosed and
does not solicit any external probing. 

Also parsing a packet on traffic path in particular deep looking into
its
body to digest certain information elements is not a good idea for the
transport function provided by a service provider network. In lab test,
you will see the performance drop resulted from implementation of the
idea. 

But a service provider would not be blind certainly on how its transport
goes. It needs some good measurements within its domain for the purpose
of ensuring the SLA. SubRTCP is just one way of achieving this goal. We
are also drafting something more powerful from this perspective.

To have a middlebox continuously digest something unecessary is not
preferred and performance economic. 

I understand the beauty of having the whole thing under on governor but
the fact is the world will have many presidents regardlessly.

Regarding the hop limit I mentioned in my last email, I did not mean 
the TTL (IPv4) or Hop Limit (IPv6) fields in IP header. I do not know
what you meant in one of your comments. The hop limit on my mind is
for the RTP plane specifically.

Just share some general thoughts which might be better than digging to
details at this moment. But no matter what, the goal is to solve 
issues facing owners of RTP transport networks. A RTP path can originate
from one enterprise through multiple service providers to another
enterprise.

Separation of SSRC spaces between internal (transport) and true
endpoints
can solve the problem better.

Thanks,
Xiaode

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]] 
Sent: Sunday, February 11, 2007 10:59 AM
To: Xiaode Xu (xdxu)
Cc: [email-masked]; AVT WG
Subject: Re: [AVT] Re: I-D ACTION:draft-xu-avt-subrtcp-00.txt 

>>   In this case, T1 and T2 needs to create their own SSRC and spread 
>> to
> across all

>      This can ensure better accuracy of the RTT estimation. A SubRTCP 
> SR

I simply do not believe the complexity of looking at RTCP packet types
is significant compared to checking the subRTCP packet type.

>      cost and complexity and efficiency in implementation will differ.

I see the complexity as coming from introducing an additional protocol
where none is needed: subRTCP is more complex than regular RTCP.

> two values (and SR/RR packet, followed by an SDES packet). This adds 
> one extra comparison per packet, and will not cause significant delay.

>      what is being carried to process them accordingly. For example, 
> the SDES needs to be made known all the others.

> important than the end2end monitoring from a service
>      provider's purspective.

>      participants in order to get the dynamically synced report 

This has to be done for subRTCP too, if you wish to scale the reporting
interval. If no, simply send regular RTCP internal to the
infrastructure.

> association of RTP systems that includes the middleboxes and end point

> is a single RTP session, with associated RTCP. RTCP is explicitly 
> intended to allow the type of monitoring you desire as part of its 
> "true meaningful sense".
>

-- 
Colin Perkins
http://csperkins.org/