Re: [tram] I-D Action: draft-thomson-tram-turn-bandwidth-00.txt

"Pal Martinsen (palmarti)" <palmarti@cisco.com> Wed, 19 February 2014 09:48 UTC

Return-Path: <palmarti@cisco.com>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8BC61A012B for <tram@ietfa.amsl.com>; Wed, 19 Feb 2014 01:48:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.049
X-Spam-Level:
X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 Pbot4wfmPTdB for <tram@ietfa.amsl.com>; Wed, 19 Feb 2014 01:48:00 -0800 (PST)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 6777A1A00B7 for <tram@ietf.org>; Wed, 19 Feb 2014 01:47:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2999; q=dns/txt; s=iport; t=1392803275; x=1394012875; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Wjxxvm+wjRtaD8ULO31v9xGW6+/vKMdxi5Q7eprGv54=; b=PsBIVT355yBef4Ds62e9Q+CkXimlVHBILY6GGI6waqxH3x0kD/h5vyED CNO0ZsLB3EBQxYsA81DSDJwMD07It/czpiv/5cpXaJpy3srbDs8VExDFr DvAGSPXHGbNXc/yXaK9XI7h3W4ElrvC4S+lT2Bgai2skm1JxndXKfivyU Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAJF9BFOtJV2Y/2dsb2JhbABZgwaBD790gRwWdIImAQEEeRACAQhGMiUCBA4gh2rNQheOAy4zB4MkgRQEmDCSJIMtgWlB
X-IronPort-AV: E=Sophos;i="4.97,504,1389744000"; d="scan'208";a="21512573"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-1.cisco.com with ESMTP; 19 Feb 2014 09:47:55 +0000
Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1J9ltw3028596 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Feb 2014 09:47:55 GMT
Received: from xmb-rcd-x06.cisco.com ([169.254.6.236]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Wed, 19 Feb 2014 03:47:54 -0600
From: "Pal Martinsen (palmarti)" <palmarti@cisco.com>
To: "tram@ietf.org" <tram@ietf.org>
Thread-Topic: [tram] I-D Action: draft-thomson-tram-turn-bandwidth-00.txt
Thread-Index: AQHPLVepL0ox0vNFkUCS65m4/NS1Cw==
Date: Wed, 19 Feb 2014 09:47:54 +0000
Message-ID: <6BAD559F-A526-4215-A566-9A21632AED08@cisco.com>
References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <CAKhHsXGzA=ZTFGTK7ht9hQbfG70iqKrDtxrZCdQNNMzBYZCk8A@mail.gmail.com> <E721D8C6A2E1544DB2DEBC313AF54DE224412306@xmb-rcd-x02.cisco.com> <5303A4DE.8090500@viagenie.ca> <CALDtMrKN8hhDVLZQnPjPNkA=vBe0mznfxDpiAOx=uhkmw8PUHQ@mail.gmail.com> <5303D18C.5030705@viagenie.ca> <CALDtMr+0H=Qf7PxWD2=QpjCE9gTAFn9tWcjkkoaZyXfepAQHKw@mail.gmail.com> <E721D8C6A2E1544DB2DEBC313AF54DE224413A26@xmb-rcd-x02.cisco.com>
In-Reply-To: <E721D8C6A2E1544DB2DEBC313AF54DE224413A26@xmb-rcd-x02.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.55.154.70]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <94487ACD54F65C4AA0D06D89FCA59EA8@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tram/ZPd4njk9T6JCKGqmsk7-fJj-xwM
Cc: "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com>, Oleg Moskalenko <mom040267@gmail.com>, Simon Perreault <simon.perreault@viagenie.ca>
Subject: Re: [tram] I-D Action: draft-thomson-tram-turn-bandwidth-00.txt
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Feb 2014 09:48:04 -0000

Hi,

I like the idea of a bandwidth attribute telling the TURN server what to expect from that particular allocation. Especially when it comes to allocations that carry for example RTCP, BFCP and other “low chatter” data protocols. When it comes to more “elastic” media protocols (video especially) a static bandwidth attribute can be a bit problematic. This is somewhat described in the draft that burst above the maximum should be expected. But due to very good video encoding efficiency in for example a talking head only scenario, the bandwidth usage may be significantly lower than the maximum bandwidth the agent signalled in the allocation message. 

So how is this bandwidth attribute useful for the TURN server when signalled from the allocating agent? What can it do when the bandwidth is exceeded, and when does it know that the bandwidth is exceeded? There might be different network paths to the TURN server. One path may be congested well before any TURN bandwidth is exceeded. 

I am trying to argue that the possible choke point in the network is not necessarily where the TURN server is placed, and that reduces the usefulness of a bandwidth attribute in some scenarios. When it comes to draft-thomson-tram-turn-bandwidth we must be careful to explain what problems it solves. I am afraid that this attribute might be (miss?)used as a QoS solution on the entire media path. 

One possible use case for this draft to solve is to get better pr session/call/?? bandwidth utilisation.  If for example a user pays to get 3Mbit through the TURN server. The users endpoint is capable of sending 1 audio and 3 video (Head, room and slides) streams and one BFCP stream. The agent needs to do 9 allocations (4xRTP, 4xRTCP, 1xBFCP), 5 of those allocations are very low bandwidth. The agent itself knows best how to utilise the remaining bandwidth, but how should we cope with changing needs. How do we signal; I know that I have 3Mbit available, and I am dynamically going to use that bandwidth over those 4 allocations, and by the way I have 5 more allocations that only needs a packet sent now and then.. (And yes I know of BUNDLE, but the media streams may not have the same src/dst IP)

When it comes to DSCP and ECN, as Simon point out putting them in a STUN attribute would help getting the values transported unmangled over the Internet. This is especially important in this scenario as a NAT sitting between the agent and the TURN server might ignore those bits when forwarding the packets. The remaining problem with DSCP is that there is no strict defining of what the bits actually means. Some definitions can be found in draft-dhesikan-tsvwg-rtcweb-qos, but it is likely that different ISPs or networks will use different values. As Muthu pointed out, this is essentially the motivation for the  draft-martinsen-tram-discuss draft.

.-.
Pål-Erik