Subject: RE: [MMUSIC] I-D ACTION:draft-ietf-mmusic-media-loopback-02.txt

From: "Hedayat, Kaynam" <[email-masked]>
Date: Tue, 21 Feb 2006 17:21:30 -0500

Colin,

Thanks for the comments. Please see my answers below.

Regards,
Kaynam 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Colin Perkins
> Sent: Thursday, November 24, 2005 8:23 AM
> To: IETF MMUSIC working group
> Subject: Re: [MMUSIC] I-D 
> ACTION:draft-ietf-mmusic-media-loopback-02.txt 
> 
> On 8 Nov 2005, at 23:50, [email-masked] wrote:
> > A New Internet-Draft is available from the on-line Internet-Drafts 
> > directories.
> > This draft is a work item of the Multiparty Multimedia 
> Session Control 
> > Working Group of the IETF.
> >
> > 	Title		: An Extension to the Session Description
> >                           Protocol (SDP) for Media Loopback
> > 	Author(s)	: K. Hedayat, et al.
> > 	Filename	: draft-ietf-mmusic-media-loopback-02.txt
> > 	Pages		: 17
> > 	Date		: 2005-11-8
> > 	
> > The wide deployment of VoIP and Video over IP services has
> >     introduced new challenges in managing and maintaining 
> voice/video
> >     quality, reliability, and overall performance.  In particular,
> >     media delivery is an area that needs attention.  One method of
> >     meeting these challenges is monitoring the media delivery
> >     performance by looping media back to the transmitter.  This is
> >     typically referred to as "active monitoring" of 
> services.   Media
> >     loopback is especially popular in ensuring the quality of 
> > transport
> >     to the edge of a given VoIP or Video over IP service.  Today in
> >     networks that deliver real-time media, short of running 
> 'ping' and
> >     'traceroute' to the edge, service providers are left without the
> >     necessary tools to actively monitor, manage, and 
> diagnose quality
> >     issues with their service.  The extension defined 
> herein adds new
> >     SDP media attributes which enables establishment of 
> media sessions
> >     where the media is looped back to the transmitter. Such media
> >     sessions will serve as monitoring and troubleshooting tools by
> >     providing the means for measurement of more advanced VoIP and 
> > Video
> >     Over IP performance metrics.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-media-
> > loopback-02.txt
> 
> Some comments on this draft:
> 
> 1) The description of how rtp-pkt-loopback interacts with 
> normal RTP header processing should be expanded. The data is 
> supposed to be re- encapsulated for transmission back to the 
> source, but how that is done is not well-specified. Should 
> the answering entity use the same payload format as the 
> original, or should the data be transcoded or somehow 
> encapsulated in a new stream of RTP packets? If the original 
> format is used, how is packet loss handled (what if the 
> payload format is aware of sequence numbers)? If 
> encapsulating, what is the encapsulation format? How are 
> path-MTU limitations handled?
We originally had a simpler concept of loopback and decided to change it
for more visibility into packet loss in both directions. Obviously based
on your input this approach is broken. I suggest going back to the
original approach where RTP packets are looped back without any changes
in the header but the SSRC. Packets are looped back in their original
format as soon as they arrived at the mirror endpoint. The mirror
endpoint only has to change the SSRC field. This approach improves the
performance as well.
> 
> 2) How is congestion on the reverse path handled?
It should be handled similar to any other RTP stream generated by the
endpoint.
> 
> 3) The security considerations should discuss how to avoid 
> packet bombing an unsuspecting third party. The draft states 
> that authentication is needed, but I think it needs to 
> provide more details (e.g. give an example of what sort of 
> authentication can be used; how it prevent the problem).
The media loopback is accepted in the context of a call. The security
aspects must be treated similar to normal calls.
> 
> Colin
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mmusic
> 

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic