[AVTCORE] Comments on draft-ietf-avtcore-rfc5764-mux-fixes-03.txt

Magnus Westerlund <magnus.westerlund@ericsson.com> Tue, 20 October 2015 10:49 UTC

Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9E341B329A; Tue, 20 Oct 2015 03:49:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
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 8QnaDUADKkvh; Tue, 20 Oct 2015 03:49:35 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE54E1B3297; Tue, 20 Oct 2015 03:49:31 -0700 (PDT)
X-AuditID: c1b4fb30-f79626d000006adf-68-56261c3ac4bf
Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 10.F7.27359.A3C16265; Tue, 20 Oct 2015 12:49:30 +0200 (CEST)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.47) with Microsoft SMTP Server id 14.3.248.2; Tue, 20 Oct 2015 12:49:29 +0200
References: <20151019221040.17412.81332.idtracker@ietfa.amsl.com>
To: avt@ietf.org, draft-ietf-avtcore-rfc5764-mux-fixes@ietf.org
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
Message-ID: <56261C39.8060208@ericsson.com>
Date: Tue, 20 Oct 2015 12:49:29 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <20151019221040.17412.81332.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprELMWRmVeSWpSXmKPExsUyM+Jvja6VjFqYwaPrAhYve1ayWxz4OJXZ gcljyZKfTAGMUVw2Kak5mWWpRfp2CVwZd87PZyl4LFDx5+xU5gbGnbxdjJwcEgImEvO2/GeD sMUkLtxbD2YLCRxllDi+urCLkQvIXs4o8f5gPxNIQljAQeLAnG2MEEWOErMbullAbBEBZ4mZ X78yg9hsAhYSN380gg3iFdCWaN3bD2azCKhKTP01E8wWFYiReL9pFSNEjaDEyZlPwOZwCjhJ 7NhxhLWLkYODWcBe4sHWMpAws4C8RPPW2cwQa7UlGpo6WCcwCsxC0j0LoWMWko4FjMyrGEWL U4uTctONjPRSizKTi4vz8/TyUks2MQID8eCW3wY7GF8+dzzEKMDBqMTD+yBdNUyINbGsuDL3 EKM0B4uSOG8z04NQIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYypH0rlfSf9Ngzf8H7WzdsB 0w/ePCU8I++P0fS6SQ5ywk+2bmuYyi695dWBklcLa6QM124In3vS5eb3Eyka22sYPj6/uyDo YPLkXRuOli+7+k5r8qoVuxdK555LaBO6sJlt/WHNBS6zT3vH/bI6zrtmXtI5xj7LpL5I9YJJ 82Ozrt11+mKgt3ORoBJLcUaioRZzUXEiANBSu90lAgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/aelFDwaCnR_S9DcyL_wqKsbRmug>
Subject: [AVTCORE] Comments on draft-ietf-avtcore-rfc5764-mux-fixes-03.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 20 Oct 2015 10:49:37 -0000

Hi,

I have looked at the updated draft. I think you have resolved my 
previous comments, thank you. However, I still have some comments.

1. Split the introduction chapter. The introduction is much more than an 
introduction. I think the sub-sections likely belong in a new section 
after the introduction that discusses the issues and intended changes in 
depth. However, they are not introduction.

2. Section 1.3:

I still are uncertain if TURN channels needs the whole range 64 to 79. I 
think the text should be explicit about how many turn channels this 
support. So according to my math the proposed change is from 64-127 to 
64-79, i.e. the available number of channels has been reduced from 16384 
to 4096. That still a large number of channels.

What number of channels are currently used by implementations? I expect 
that to be single digit, or am I missing some use cases?

3.  Section 1.4:

I still don't see how what is written in this section results in any 
improvement. You authors have assumptions of how this needs to be 
implemented that isn't written down. Looking on this problem of 
demultiplexing I would build a table driven solution based on the 
ranges, where the packet is sent to the relevant protocol based on the 
table-lookup. If that protocol don't use that value, that will be the 
end of the road for that packet as invalid, rather than giving it to any 
other protocol. I get the impression that you want one to send the 
packet for testing by the protocols one after each other according to 
the order the protocols are listed. I still don't see that 
implementations will do that.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------