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

Hi Oleg,

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

On 12 Feb 2014, at 10:10 am, Oleg Moskalenko <mom040267@gmail.com<mailto:mom040267@gmail.com>> 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.

.-.
Pål-Erik

Oleg

On Wed, Feb 12, 2014 at 12:51 AM, Pal Martinsen (palmarti) <palmarti@cisco.com<mailto:palmarti@cisco.com>> 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
URL:            http://www.ietf.org/internet-drafts/draft-martinsen-tram-discuss-00.txt
Status:         https://datatracker.ietf.org/doc/draft-martinsen-tram-discuss/
Htmlized:       http://tools.ietf.org/html/draft-martinsen-tram-discuss-00

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.

.-.
Pål-Erik

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