Subject: Re: [AVTCORE] FW: New Version Notification for draft-rescorla-avtcore-6222bis-00.txt

From: Kevin Gross <[email-masked]>
Date: Mon, 5 Nov 2012 17:18:21 -0500

Since it looks like this will be accepted as a workgroup item, here are a
few comments:

I'm not clear on how a bis works but I assume this draft needs to be able
to stand on it's own as it proposes to obsolete RFC 6222. Some or all
references to RFC 6222 probably need to be removed. Particularly confusing
are statements in the abstract that seem to indicate that only parts of RFC
6222 are being replaced.

Second bullet point in section 4.2 Item (a): I don't understand how a CNAME
based on MAC address would be considered short-term. Seems like this would
have same or better persistence properties as the UUID in the first bullet
point.

Second bullet point in section 4.2 Item (b): Proposes truncating our nice
96-bit random CNAME to 48 bits. I think we have an unacceptable opportunity
for duplication with this approach. This CNAME should probably use RFC 4648
in which case these CNAMEs take the same form as the per-session CNAMES but
differ in the requirement to create once at software initialization. Is it
necessary for the different types of CNAMEs to have different appearance?

p.6: Phrase, "(to compromise between packet size and uniqueness)" is scary.
Exude more confidence here and/or insert a forward reference to section 6.1.

Section 6.1: Please provide a collision probability for a worst-case
population. 2^48 is an unreasonable population for this application (and
50% is a scary probability). Is 2^40 a worst-case population. Seems large.

Kevin Gross
+1-303-447-0517
Media Network Consultant
AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org

On Sat, Oct 13, 2012 at 10:32 PM, Ali C. Begen (abegen) <[email-masked]>wrote:

> We have submitted a draft to replace 6222. This document is a new version
> of 6222 and has the fixes proposed by Eric in the last meeting.
>
> Comments are welcome.
> -acbegen
>
> -----Original Message-----
> From: "[email-masked]" <[email-masked]>
> Date: Saturday, October 13, 2012 10:30 PM
> To: "Ali C. Begen" <[email-masked]>
> Cc: "Eric com>" <[email-masked]>
> Subject: New Version Notification for draft-rescorla-avtcore-6222bis-00.txt
>
> >
> >A new version of I-D, draft-rescorla-avtcore-6222bis-00.txt
> >has been successfully submitted by Ali Begen and posted to the
> >IETF repository.
> >
> >Filename:       draft-rescorla-avtcore-6222bis
> >Revision:       00
> >Title:          Guidelines for Choosing RTP Control Protocol (RTCP)
> Canonical
> >Names (CNAMEs)
> >Creation date:  2012-10-14
> >WG ID:          Individual Submission
> >Number of pages: 10
> >URL:
> >http://www.ietf.org/internet-drafts/draft-rescorla-avtcore-6222bis-00.txt
> >Status:
> >http://datatracker.ietf.org/doc/draft-rescorla-avtcore-6222bis
> >Htmlized:
> >http://tools.ietf.org/html/draft-rescorla-avtcore-6222bis-00
> >
> >
> >Abstract:
> >   The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a
> >   persistent transport-level identifier for an RTP endpoint.  While the
> >   Synchronization Source (SSRC) identifier of an RTP endpoint may
> >   change if a collision is detected or when the RTP application is
> >   restarted, its RTCP CNAME is meant to stay unchanged, so that RTP
> >   endpoints can be uniquely identified and associated with their RTP
> >   media streams.
> >
> >   For proper functionality, RTCP CNAMEs should be unique within the
> >   participants of an RTP session.  However, the existing guidelines for
> >   choosing the RTCP CNAME provided in the RTP standard are insufficient
> >   to achieve this uniqueness.  RFC 6222 was published to update those
> >   guidelines to allow endpoints to choose unique RTCP CNAMEs.
> >   Unfortunately, later investigations showed that some parts of the new
> >   algorithms were unnecessarily complicated and/or ineffective.  This
> >   document specifies a replacement for those parts.
> >
> >
> >
> >
> >
> >The IETF Secretariat
> >
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 6 Nov 2012 00:02:16 +0000

From:  Kevin Gross <[email-masked]>
Date:  Monday, November 5, 2012 6:18 PM
To:  "Ali C. Begen" <[email-masked]>
Cc:  "[email-masked]" <[email-masked]>
Subject:  Re: [AVTCORE] FW: New Version Notification for
draft-rescorla-avtcore-6222bis-00.txt

>references to RFC 6222 probably need to be removed. Particularly
>confusing are statements in the abstract that
> seem to indicate that only parts of RFC 6222 are being replaced.
>

I think it is ok to refer to 6222 to explain what things caused a concern
and are being fixed in this document.Now reading the last sentence in the
abstract, yeah, it sounds a bit funny. It should rather say "This document
addresses these concerns and replaces RFC 6222."

>
>Second bullet point in section 4.2 Item (a): I don't understand how a
>CNAME based on MAC address would be considered short-term. Seems like
>this would have same or better persistence properties as the UUID in the
>first bullet point.

Well, there could be multiple MACs associated with an endpoint and they
could be changed via software, etc. So, I don't think it is as persistent
as UUID.

>96-bit random CNAME to 48 bits. I think we have an unacceptable
>opportunity for duplication with this approach. This CNAME should
>probably use RFC 4648 in which case these CNAMEs
> take the same form as the per-session CNAMES but differ in the
>requirement to create once at software initialization. Is it necessary
>for the different types of CNAMEs to have different appearance?

I don¹t think there is such a requirement and your suggestion makes sense.
BTW, there is a sentence that needs to be deleted here (artifact from
6222): "hence, only the initial SSRC value chosen by the endpoint is used"

>
>p.6: Phrase, "(to compromise between packet size and uniqueness)" is
>scary. Exude more confidence here and/or insert a forward reference to
>section 6.1.

OK.

>population. 2^48 is an unreasonable population for this application
> (and 50% is a scary probability). Is 2^40 a worst-case population. Seems
>large.

Eric, do you have any numbers here?

-acbegen

><http://www.X192.org>
>On Sat, Oct 13, 2012 at 10:32 PM, Ali C. Begen (abegen)
><[email-masked]> wrote:
>