IETF Logo Mail Archive

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

Michael Hammer <michael.hammer@yaanatech.com> Thu, 20 February 2014 19:30 UTC

Return-Path: <michael.hammer@yaanatech.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 B7DD21A015F for <tram@ietfa.amsl.com>; Thu, 20 Feb 2014 11:30:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level:
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, 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 1K8UggzkWsM8 for <tram@ietfa.amsl.com>; Thu, 20 Feb 2014 11:30:24 -0800 (PST)
Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3B01A01F2 for <tram@ietf.org>; Thu, 20 Feb 2014 11:30:24 -0800 (PST)
Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.03.0123.003; Thu, 20 Feb 2014 11:30:22 -0800
From: Michael Hammer <michael.hammer@yaanatech.com>
To: "mom040267@gmail.com" <mom040267@gmail.com>, "pkyzivat@alum.mit.edu" <pkyzivat@alum.mit.edu>
Thread-Topic: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt
Thread-Index: AQHPLBx+/w69jI7P3kSEjcKKvn9TyZq+N0pvgAC84wCAABR3AP//fjwwgACJGYCAAADugP//emRA
Date: Thu, 20 Feb 2014 19:30:21 +0000
Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBF3186E@sc9-ex2k10mb1.corp.yaanatech.com>
References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <CAKhHsXGzA=ZTFGTK7ht9hQbfG70iqKrDtxrZCdQNNMzBYZCk8A@mail.gmail.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> <CAKhHsXGsp6ma6Ko9op+YFRqSGM_Ex-jFo_fjz69rN0SEHfNK2A@mail.gmail.com> <CALDtMrKb3_38Rs0vaGnpEvNvTYz8YUTo89STvLJNXfkfdipDSQ@mail.gmail.com> <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com> <00C069FD01E0324C9FFCADF539701DB3BBF3175B@sc9-ex2k10mb1.corp.yaanatech.com> <530655DF.6080604@alum.mit.edu> <CALDtMrLnURRgxAm34TwV5yUyfUCNDGC440AJnHvo96gmj0V9+Q@mail.gmail.com>
In-Reply-To: <CALDtMrLnURRgxAm34TwV5yUyfUCNDGC440AJnHvo96gmj0V9+Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.17.100.163]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_024C_01CF2E48.483ACD90"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tram/eqROx4G_SZxZq7FoDglHATiKiz0
Cc: "tram@ietf.org" <tram@ietf.org>
Subject: Re: [tram] Fwd: 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: Thu, 20 Feb 2014 19:30:27 -0000

Paul,

 

Speaking loosely.

Meant in the same vein that architecturally, SIP, SDP, RTP, STUN, TURN, ICE,
etc.

Know how to work collectively, so you don't have to design this
monolithically into one protocol.

SDP knows how to select codecs, no?

I would hope that IETF doesn't create so many that it needs to be
negotiated.

Hope you catch my drift now.

 

Yes, was hoping that if architecture vision indicates how to separate these
protocols, 

then we can postpone discussion on QoS to another WG to address, if it
hasn't already.

 

Michael Hammer

Principal Engineer

 <mailto:michael.hammer@yaanatech.com> michael.hammer@yaanatech.com

Mobile: +1 408-202-9291

500 Yosemite Drive Suite 120

Milpitas, CA 95035 USA

 

From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Oleg Moskalenko
Sent: Thursday, February 20, 2014 2:25 PM
To: Paul Kyzivat
Cc: tram@ietf.org
Subject: Re: [tram] Fwd: I-D Action:
draft-thomson-tram-turn-bandwidth-00.txt

 

Obviously, a "link to API" means here "a URL/URI to REST API to QoS".

I am not sure that such  web-based API exist. May be, a custom proprietary
implementation can be used.

But I'd postpone any discussion on that matter.

 

 

On Thu, Feb 20, 2014 at 11:22 AM, Paul Kyzivat <pkyzivat@alum.mit.edu>
wrote:

On 2/20/14 2:12 PM, Michael Hammer wrote:

Perhaps one thing TRAM signaling can return to the client is a link to
an API for doing QoS control.

Then whatever QoS control protocol you want to use could be patched in.

Might make this a little more future proof.

 

"A link to an API"?????

AFAIK that doesn't make sense.

A link that identifies a target and protocol to control QoS makes some sense
to me. But then how do you know the client will support the protocol you are
offering?

        Thanks,
        Paul



_______________________________________________
tram mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram

v2.23.0 | Report a Bug | By Email