Re: [tram] Communication between app and network using STUN

"Pal Martinsen (palmarti)" <> Wed, 12 February 2014 09:58 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 474B61A090F for <>; Wed, 12 Feb 2014 01:58:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.048
X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vgBbmi5UiB7L for <>; Wed, 12 Feb 2014 01:58:08 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 519751A090B for <>; Wed, 12 Feb 2014 01:58:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=9081; q=dns/txt; s=iport; t=1392199088; x=1393408688; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=sjqblz+P/U5emo2vUmb5MIbohlHr6Km4dQziE8MQmj0=; b=eQtzReXG7Dz0tqGjTGwSPWin/Rj5sZQsYDjLkusREMiTBRJIx6yhP5iQ IXgmrBOCugbB2JyolXCEXHtu3Ac1TpljqZMulA14/BLsnWPR/RUVWAABt WohshVqhXuQBX4Vyokx44INcjqQwF4icrOjfACNyGOAnqSsEl4TM9JDJl U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="4.95,831,1384300800"; d="scan'208,217"; a="303494849"
Received: from ([]) by with ESMTP; 12 Feb 2014 09:58:07 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s1C9w76u012037 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Feb 2014 09:58:07 GMT
Received: from ([]) by ([]) with mapi id 14.03.0123.003; Wed, 12 Feb 2014 03:58:07 -0600
From: "Pal Martinsen (palmarti)" <>
To: Oleg Moskalenko <>
Thread-Topic: [tram] Communication between app and network using STUN
Thread-Index: AQHPJ8+oaj40MN8jhk2bXiv88jHOQ5qxuZCAgAANPoA=
Date: Wed, 12 Feb 2014 09:58:06 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_F08F11F333F34D06B58631ECE4B920C3ciscocom_"
MIME-Version: 1.0
Cc: "Herb Wildfeuer (hwildfeu)" <>, "" <>
Subject: Re: [tram] Communication between app and network using STUN
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 12 Feb 2014 09:58:11 -0000

Hi Oleg,

That was an impressive quick read. Thanks for the interest.

On 12 Feb 2014, at 10:10 am, Oleg Moskalenko <<>> wrote:

Question (or comment) on Section 6.3:

Can the application be behind a NAT ? Can a NAT be involved ?
Yes. That is the beauty of in-band STUN signalling.

If yes, then all applications behind that NAT may have the same IP address, from the STUN message receiver point of view. Then how the Session ID and the priority works in such a case ?

It wont. Unless we come up with something clever..

So the problem is if that you have a system that produces  a main video stream from one IP and a presentation video stream from another IP? You would like the network to know that you care more about the main video, and if problems occur it should preferably drop packets from the presentation stream. And this should be up to the application to choose, in another situation it might be the presentation video stream that is the most important (It might dynamically change during the conference as well).

The main rationale for limiting it to the IP address was to reduce the incentive to lie about the priorities. It does not get you better bandwidth, it just tells the network what to which of your own packets to drop if there is a problem. It might be worth having a stronger id to allow us to loosen the IP address requirements.

What I am afraid of is to open up for cross application priorities. That is a rathole I would like to avoid for now.



On Wed, Feb 12, 2014 at 12:51 AM, Pal Martinsen (palmarti) <<>> wrote:

Hi Tramsters,

We published a draft today describing extensions to STUN that enables simple communication between the endpoint and the network.

Name:           draft-martinsen-tram-discuss
Revision:       00
Title:          Differentiated prIorities and Status Code-points Using Stun Signalling (DISCUSS)
Document date:  2014-02-12
Group:          Individual Submission
Pages:          13

The main goals for now:

 - Make it easy for an application to communicate its intent to the network (QoE) without needing access to the lower layers of the IP stack. Sending a STUN packet would be an easy solution for the application.
- Make it easy for the network to process information from the endpoint. STUN have nice characteristics that makes it easy for network elements to pick it up.
- Create a tightly defined set of STUN attributes that does not leak unnecessary information.

To describe the draft using established mechanisms; think of it as extended DSCP markings with ECN capabilities sent in-band using STUN.

I realize the TRAM agenda is packet, but hopefully we would fine time to discuss if this is something useful that fits under the TRAM charter.


tram mailing list<>