[AVTCORE] Spencer Dawkins' Discuss on draft-ietf-avtcore-rtp-multi-stream-optimisation-09: (with DISCUSS and COMMENT)

"Spencer Dawkins" <spencerdawkins.ietf@gmail.com> Thu, 03 December 2015 05:48 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: avt@ietf.org
Delivered-To: avt@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 70A6C1A1BA3; Wed, 2 Dec 2015 21:48:35 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Spencer Dawkins <spencerdawkins.ietf@gmail.com>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.11.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20151203054835.3796.523.idtracker@ietfa.amsl.com>
Date: Wed, 02 Dec 2015 21:48:35 -0800
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/vzmp0MiIwkcSXBnZyLn-jQEKIoQ>
Cc: avtcore-chairs@ietf.org, draft-ietf-avtcore-rtp-multi-stream-optimisation@ietf.org, avt@ietf.org
Subject: [AVTCORE] Spencer Dawkins' Discuss on draft-ietf-avtcore-rtp-multi-stream-optimisation-09: (with DISCUSS and COMMENT)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Dec 2015 05:48:35 -0000

Spencer Dawkins has entered the following ballot position for
draft-ietf-avtcore-rtp-multi-stream-optimisation-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-multi-stream-optimisation/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I'm lost on something here, so I'd like to discuss it briefly so that I
understand what I'm looking at. I'm not expecting this to be hard to
resolve.

In this text

   However, the three
   SSRCs comprising each participant will almost certainly see identical
   reception quality, since they are co-located.
   
it sounds like you're describing a heuristic ("will almost certainly
see", so if you use a reporting group, the results will be close enough).


In other places in the document, like

   Since they are co-located, every
   SSRC in the RTCP reporting group will have an identical view of the
   network conditions, and see the same lost packets, jitter, etc.  
   
it sounds like you're saying they'll always have an identical view ("will
see", with no qualification). 

Which is it?

As a comment, but on exactly the second text so I'll include it here, is
"see the same lost packets" telling me that more than one SSRC is sending
"the same lost packets"? If this was "see (roughly) the same loss rate",
I wouldn't be surprised, but I'm confused here.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

This text 

   An RTP endpoint will have one or more synchronisation sources (SSRCs)
   that send media streams.  It will have at least one SSRC for each
   media stream it sends, and might use multiple SSRCs when using media
   scalability features [RFC6190], forward error correction, RTP
   retransmission [RFC4588], or similar mechanisms.  An endpoint that is
   not sending any media streams, will have at least one SSRC to use for
   reporting and any feedback messages.  

was somewhat confusing for me. It's saying that an RTP endpoint will
always have one or more SSRCs that send media streams, except that it
might not send media streams, but then it still has at least one SSRC
that doesn't send a media stream. Could you think about whether this
could be clearer?