Re: [MMUSIC] WGLC of draft-ietf-mmusic-media-loopback-18

Magnus Westerlund <magnus.westerlund@ericsson.com> Fri, 13 April 2012 12:22 UTC

Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F39A921F8494 for <mmusic@ietfa.amsl.com>; Fri, 13 Apr 2012 05:22:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.192
X-Spam-Level:
X-Spam-Status: No, score=-106.192 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpb2N33PBPix for <mmusic@ietfa.amsl.com>; Fri, 13 Apr 2012 05:22:06 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id D21ED21F8496 for <mmusic@ietf.org>; Fri, 13 Apr 2012 05:22:05 -0700 (PDT)
X-AuditID: c1b4fb25-b7b18ae000000dce-2d-4f881a6cb675
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id D8.FC.03534.C6A188F4; Fri, 13 Apr 2012 14:22:04 +0200 (CEST)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.213.0; Fri, 13 Apr 2012 14:22:04 +0200
Message-ID: <4F881A6B.7080308@ericsson.com>
Date: Fri, 13 Apr 2012 14:22:03 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: "Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com>
References: <4F79A716.3080804@ericsson.com>
In-Reply-To: <4F79A716.3080804@ericsson.com>
X-Enigmail-Version: 1.4
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
Cc: "draft-ietf-mmusic-media-loopback.authors@tools.ietf.org" <draft-ietf-mmusic-media-loopback.authors@tools.ietf.org>, Flemming Andreasen <fandreas@cisco.com>, mmusic <mmusic@ietf.org>
Subject: Re: [MMUSIC] WGLC of draft-ietf-mmusic-media-loopback-18
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Apr 2012 12:22:07 -0000

Hi,

I have reviewed the version in WGLC. I have some few comments:

1. Section 5.5:
"Note that for any form of NAT traversal to function, symmetric
    RTP/RTCP MUST be used."

Any reason to no reference RFC 4961 here?

2. Section 7.1.1 to 7.1.3 and 7.2.1 to 7.2.3 all are missing a space
between the section number and the section title.

3. Section 6:
 A loopback mirror that is compliant to this specification and
    accepts media with rtp-pkt-loopback loopback-type MUST loopback the
    incoming RTP packets using either the encapsulated RTP payload
    format or the direct loopback RTP payload format as defined in
    section 7 of this specification.

I don't think this has addressed my previous WG last call comment about
that the MUST needs an escape clause or at least a pointer to the issue
of congestion control. Because if you have no escape clause then the
loopback source MUST perform congestion control not only on the path
from the source to the mirror, but also on the mirror to the source.

4. Section 7.1.2:
    The outer RTP header of the encapsulating packet MUST be followed
    by the payload header defined in this section.  If the received RTP
    packet has to be looped back in multiple encapsulating packets due
    to fragmentation, the encapsulating RTP header in each packet MUST
    be followed by the payload header defined in this section.

I think this is are unfortunate formulations as it actually defines that
RTP header extensions and CSRC lists are not allowed. Especially header
extensions should not be disallowed. I would suggest a formulation saying:

The RTP payload of the encapsulating RTP packet starts with the payload
header defined in this section.

And go on and define the payload structure in relation to the start of
the payload.

5. Section 7.1.2:
    The
    Receive timestamp MUST be based on the same clock used by the
    loopback-source.

I still think this formulation is extremely wrong. One alternative is
the same clocks source, like if they where using the same NTP server. Or
is it actually "clock rate" that is intended here?

Se my previous comment 28 for more input about this:
http://www.ietf.org/mail-archive/web/mmusic/current/msg08971.html


6. I can't locate any answer to my issue number 30:

30. Section 7.2.1:
Sequence Number: The RTP sequence number SHOULD be generated by the
    loopback-mirror in the usual manner with a constant random offset.

What is the acceptable cases for when to break it? I assume the
intention with not saying MUST is that one can copy it from the
incomming packet. Thus when source -> mirror packet losses occur causing
wholes in the return path which isn't real loss on the mirror->source
path. It also causes third party monitor to report losses that aren't
real on this stream.

Can you please summarize any discussion that has happened?

7. I also don't see any changes related to my comment 34:

"34. Section 9.
This section is thoroughly inadequate. The reason is that you have a
forward path that is coupled to the reverse path. If the loopback is to
work correctly the mirror needs to be able to send back what the source
sent to it. Thus it is the loopback source that needs to adapt the media
bit-rate so that both forward and reverse path can handle the flows. If
doesn't the mirror will need to reduce the bit-rate it transmits and
that can only happen in two ways, dropping packets or transcoding them
to a lower rate fulfilling the congestion control requirement. Neither
will fulfill the purpose of the loopback as I see it. This issue needs
discussion, including some considerations in how to actually accomplish
it with the tools we have available."

This is coupled to issue 3 above. If that above MUST stands you
absolutely have to have more detailed discussion about dealing with the
whole loop, rather than a single leg that is the norm.

8. Section 11.

The amplification or reflection this allows has at least been
sufficiently discussed. I am far from certain that the mitigation is
clear enough.

I do support Flemming's comment about the SRTP implications of using
loopback are.

9. Another not addressed issue:

41. The media type registrations "rate" parameter I think needs to be
redefined. It needs to reference the rate of the payload types it
intends to mirror back.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------