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

From: "Miguel A. Garcia" <[email-masked]>
Date: Mon, 2 Apr 2012 15:18:14 +0200

This is to start a 2-week Working Group Last Call for

        draft-ietf-mmusic-media-loopback-18.txt

The WGLC ends on April 16th, 2012.

Please reply to this e-mail to send comments, so that the authors and the 
mailing list are all copied.

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Tue, 10 Apr 2012 09:18:24 +0200

A short note:

A reviewer of Media MIME types team sent some minor/editorial comments to 
Section 13 of the draft.

The review is available here:

http://www.ietf.org/mail-archive/web/ietf-types/current/msg01649.html

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 10 Apr 2012 12:39:35 -0400

I have reviewed loopback-18 and have a couple of comments:

General:
- I'm missing considerations around SRTP. It needs to be described in 
here how that works (e.g. what do you copy for RTP packet loopback and 
just be clear that each side does its normaly SRTP processing on both 
send and receive).

Specific sections:
- Abstract and Introduction: Says it defines new SDP media attributes. 
Should also mention it defines new MIME types

- 3.2, first paragraph:
Change "specific media types" to "specific media descriptions"
I believe the "MAY" should be a "MUST"

- 4.1, first paragraph
Change "property media attribute" to "value media attribute" and add 
reference to [RFC4566]

- 4.2, first paragraph
Change "value media attribute" to "property media attribute" and add 
reference to [RFC4566]

- 5.1, third paragraph
Instead of "terminate the session", we should rather just talk about 
"reject the offer".

- 5.2, first paragraph
add "and hence MUST NOT be used" to the end.

- 5.2
The first two examples use RFC 2119 language ("MUST") whereas the last 
one does not. Given these are examples, I think they should all use 
lower-case "must"

-6, third paragraph
rtp-media-loopback gets congestion considerations, whereas 
rtp-pkt-loopback in the the preceding paragraph does not. I believe it 
applies equally well to both.

- 7, second paragraph
Overall, I find this paragraph difficult to follow - it would be helpful 
to rephrase and/or elaborate.
<quote>
To keep the implementation of loopback-mirrors simple it is
     mandated that no payload format other than encapsulated or direct
     loopback formats can be used in the packets generated by a
     loopback-mirror. As described in RFC 3550 [RFC3550], sequence
     numbers and timestamps in the RTP header are generated with initial
     random values for security reasons. If this were not mandated and
     the source payload is sequence number aware, the loopback-mirror
     will be required to understand that payload format to generate
     looped back packets that do not violate RFC 3550 [RFC3550].
     Requiring looped back packets to be in one of the two formats means
     loopback-mirror does not have to look into the actual payload
     received before generating the loopback packets.
</quote>
Some specific questions:
a) If this is only an issue for the loopback-mirror, then why do we need 
to mandate it ? If it affects the source, then we need to elaborate on 
this in the O/A section, since it presumably imposes restrictions on the 
answerer operation (that were not called out there). Also, if we keep it 
as "mandated", then we need to use RFC 2119 language instead.

b) What does "this" refer to in the third sentence. The immediately 
preceding sentence, or the one before it ?

c) The paragraph does not seem to account for the "media loopback" case. 
This is probably because it is the payload format section where media 
loopback is not defined and hence it's not intended to. It's confusing 
as it reads though.

- 11, second paragraph
s/recommended/RECOMMENDED

- 11, third paragraph
The "infinite looping" attack seems to suggest there should be some form 
of rate limiting at the mirror (would be helpful at the source as well 
of course)

- 13.2
Change from MIME to Media Type registration of RTP payload formats per 
RFC 4855.  Text in registrations need to be updated accordingly 
(s/MIME/media type/).

I have a few additional nit fixes which I will forward directly to the 
authors.

Thanks

-- Flemming

On 4/2/12 9:18 AM, Miguel A. Garcia wrote:
> Please reply to this e-mail to send comments, so that the authors and 
> the mailing list are all copied.
>
> /Miguel
>

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 13 Apr 2012 14:22:03 +0200

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: [email-masked]
----------------------------------------------------------------------

---

From: Nagarjuna Venna <[email-masked]>
Date: Fri, 13 Apr 2012 08:39:29 -0400

> http://www.ietf.org/mail-archive/web/mmusic/current/msg08971.html
Magnus,

This was intended to be "clock rate" not clock.

Regards,
nagarjuna

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 14 Apr 2012 11:52:38 +0000

Hey Magnus,
inline...

> Any reason to no reference RFC 4961 here?

Will do.

> between the section number and the section title.

Ya the formatting got screwed up by the generic text printing of the MS Word doc.

> from the source to the mirror, but also on the mirror to the source.

OK.

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

Ah sorry I thought I cleaned up that wording to make it clear.  I'll fix that.

> http://www.ietf.org/mail-archive/web/mmusic/current/msg08971.html

Sorry I meant clock rate - will change.

> Can you please summarize any discussion that has happened?

Actually there has been no discussion on this topic as far as I know - it was not a SHOULD to allow copying, it's a SHOULD because it's a SHOULD in RFC 3550.
If you'd prefer, I can just say MUST follow RFC 3550.

> whole loop, rather than a single leg that is the norm.

OK we should start a thread on this.

> I do support Flemming's comment about the SRTP implications of using

Yup.

> redefined. It needs to reference the rate of the payload types it

OK.

---

From: Gunnar Hellström <[email-masked]>
Date: Sat, 14 Apr 2012 16:07:32 +0200

I had concerns with the NAT traversal and keep-alive in earlier versions.

I am happy with the current version when the new comments and answers 
during WGLC are taken into account.

Good to see  progress.

/Gunnar

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Wed, 18 Apr 2012 14:46:25 +0200

The WGLC of draft-ietf-mmusic-media-loopback-18.txt has concluded. Thanks 
to all who provided comments.

Please authors, address the issues discussed in the last call and submit 
a new version of the document as early as you can.

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 18 Apr 2012 15:01:41 +0000

Roger, will do.

We still have on open issue on the congestion stuff, however.

-hadriel

On Apr 18, 2012, at 8:46 AM, Miguel A. Garcia wrote:

> The WGLC of draft-ietf-mmusic-media-loopback-18.txt has concluded. Thanks to all who provided comments.
> 
> Please authors, address the issues discussed in the last call and submit a new version of the document as early as you can.
> 
> /Miguel
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic