Re: [AVTCORE] I-D Action: draft-ietf-avtcore-multiplex-guidelines-12.txt

Gunnar Hellström <gunnar.hellstrom@ghaccess.se> Sat, 20 June 2020 09:38 UTC

Return-Path: <gunnar.hellstrom@ghaccess.se>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47D2C3A1104 for <avt@ietfa.amsl.com>; Sat, 20 Jun 2020 02:38:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=egensajt.se
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tsMjBAtekUJ7 for <avt@ietfa.amsl.com>; Sat, 20 Jun 2020 02:37:59 -0700 (PDT)
Received: from smtp.egensajt.se (smtp.egensajt.se [194.68.80.251]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C7F93A0A07 for <avt@ietf.org>; Sat, 20 Jun 2020 02:37:57 -0700 (PDT)
Received: from [192.168.2.136] (h83-209-156-116.cust.a3fiber.se [83.209.156.116]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: gunnar.hellstrom@ghaccess.se) by smtp.egensajt.se (Postfix) with ESMTPSA id 7AD6020159; Sat, 20 Jun 2020 11:37:55 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1592645875; bh=W8d2GmkjXfhEiGd/hsT2dGxC6WiCo9oejug23yrG5Ag=; h=Subject:To:References:From:Date:In-Reply-To:From; b=SmKzE88ja/NCFM6w6LgSaTsZtAEG7KAvu79Sy+xfynab27U+jK9jWBXVBfqrL6dIM pviAJqiwQQQv8k2nCxmJpT7UG7wrf+L+HoVXJgRoktbulciBm+vPeJZwY9xhm/+7/+ PT5cgrlLOLd922fD3rFyf8MjcQ8ACfTO8VSQflu4=
To: Magnus Westerlund <magnus.westerlund=40ericsson.com@dmarc.ietf.org>, "avt@ietf.org" <avt@ietf.org>
References: <159229666664.30176.8858768879475819006@ietfa.amsl.com> <36894aeffee62e5e982f3284b42c97b725d93555.camel@ericsson.com>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <gunnar.hellstrom@ghaccess.se>
Message-ID: <7ef7be5e-61db-e1a1-096b-e2ea8923613c@ghaccess.se>
Date: Sat, 20 Jun 2020 11:37:55 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <36894aeffee62e5e982f3284b42c97b725d93555.camel@ericsson.com>
Content-Type: multipart/alternative; boundary="------------6A79281ABED8CD502A845830"
Content-Language: sv
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/StNKv_zhJeHiUG-zGJ9oDy4wOoY>
Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-multiplex-guidelines-12.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Sat, 20 Jun 2020 09:38:03 -0000

Hi,

Thanks for an inspiring draft.

I have two issues:

1.) In section 3.4.2 it is said:

"RTP Considerations for Endpoints Sending Multiple Media Streams" 
[RFC8108 <https://tools.ietf.org/html/rfc8108>].

I first got the impression that this would refer to a section in RFC 
8108, but there is none with that title.

And it is also not the title of RFC 8108. I suggest that you update the 
string to what it was intended to refer to.

2.) I see a contradiction between two statements:

--------------------------------------------------------------------------------

I.) In 3.4 you say:    "Using multiple RTP streams is a well-supported 
feature of RTP."

II.) In 5.2, 4.b you mention a disadvantage with using multiple streams 
for the same media type in one RTP session:

"b. There is some potential for concern with legacy implementations that 
don't support the RTP specification fully when it comes to handling 
multiple SSRC per endpoint."

-------------------------------------------------------------------------------------------

Can you in some way tell for which cases there is concern and for which 
it is a well-supported feature.

My interest is for the multi-party-rtt drafts, where we have so far 
avoided the solution with multiple media streams of one media type in a 
single RTP session saying that there may be lack of support for it in 
current RTP stacks. Our current choice to instead have a mixer combine 
all streams into one stream has some disadvantages and does not seem to 
be your recommendation.

Regards

Gunnar


Den 2020-06-16 kl. 10:40, skrev Magnus Westerlund:
> WG,
>
> This version intendeds to address the issues raised during IESG review.
>
> Cheers
>
> Magnus
>
> On Tue, 2020-06-16 at 01:37 -0700, internet-drafts@ietf.org wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Audio/Video Transport Core Maintenance WG of
>> the IETF.
>>
>>          Title           : Guidelines for using the Multiplexing Features of
>> RTP to Support Multiple Media Streams
>>          Authors         : Magnus Westerlund
>>                            Bo Burman
>>                            Colin Perkins
>>                            Harald Tveit Alvestrand
>>                            Roni Even
>> 	Filename        : draft-ietf-avtcore-multiplex-guidelines-12.txt
>> 	Pages           : 43
>> 	Date            : 2020-06-16
>>
>> Abstract:
>>     The Real-time Transport Protocol (RTP) is a flexible protocol that
>>     can be used in a wide range of applications, networks, and system
>>     topologies.  That flexibility makes for wide applicability, but can
>>     complicate the application design process.  One particular design
>>     question that has received much attention is how to support multiple
>>     media streams in RTP.  This memo discusses the available options and
>>     design trade-offs, and provides guidelines on how to use the
>>     multiplexing features of RTP to support multiple media streams.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-avtcore-multiplex-guidelines/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-avtcore-multiplex-guidelines-12
>>
> https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-multiplex-guidelines-12
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-multiplex-guidelines-12
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> I-D-Announce@ietf.org
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

-- 
Gunnar Hellström
GHAccess
gunnar.hellstrom@ghaccess.se