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

From: Colin Perkins <[email-masked]>
Date: Thu, 2 Mar 2006 16:40:03 +0000

Kaynam,

On 21 Feb 2006, at 22:21, Hedayat, Kaynam wrote:
...
>> 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.

What problem are you trying to solve? If you want to understand the  
path from A->B then the packets loopback back going from B->A need to  
be encapsulated into a new RTP stream somehow, otherwise you can't  
distinguish issues on the forward and reverse paths (this would be an  
issue with the original approach). If you want to encapsulate, you  
need to specify precisely how it is to be done.

>> 2) How is congestion on the reverse path handled?
> It should be handled similar to any other RTP stream generated by the
> endpoint.

That's not possible though, since you don't have control of over the  
media encoding when looping back a stream in packet mode, and so  
can't adapt the transmission to match the reverse path  
characteristics. The draft needs a much more extensive discussion on  
this subject.

>> 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.

There are additional security considerations here though, since the  
sender controls the address to which the receiver loops back packets.  
I think the draft needs to explain how one uses authentication to  
protect against denial of service attacks, rather than simply saying  
that it can be used.

Colin

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