Subject: [BEHAVE] STUN/TURN framing or RTP framing

From: Thomas LEVY <[email-masked]>
Date: Tue, 12 Dec 2006 12:18:13 +0100

Hello all,

I have a question related to the framing mechanism for stream-oriented 
transports defined in draft-ietf-behave-turn-02.
I fully agree with the need for a framing mechanism when for instance 
STUN is over TCP.
However, it seems that the defined mechanism provides framing in 
addition with protocol identification (with the use of the Type field).
An other method for protocol identification (i.e: to distinguish STUN 
packets from others) is also defined in stun-bis with the use of  the 
magic cookie.
Furthermore, RTP already specified a framing mechanism in rfc4571 that 
could be applicable to STUN.
Thus, i am just wondering if  - when defining the framing for STUN - you 
considered using the framing defined in rfc4571?
If so, what are the reasons for the definition of a new framing?

On my opinion, i would be favorable to using the same framing for STUN 
and RTP.
My main argument is the following: If you consider a RTP client that 
wants (or needs) to carry RTP over TCP. If the client sends its media 
directly to a peer, it must use the framing rfc4571 but if the client 
sends its media through a relay (TURN) it must use the framing defined 
in draft-ietf-behave-turn-02. I think it introduces a complexity to RTP 
that shouldn't be aware of it
Furthermore, my "own personal developer experience" makes me think that 
it would be easier to functionally separate framing from protocol 
identification for the better design of a protocol stack.

Thomas

_______________________________________________
Behave mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/behave

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 12 Dec 2006 08:12:32 -0800

Hi Thomas,

The TCP framing is needed to provide the length of non-STUN data over 
TCP.
The RTP framing over TCP was considered, but TURN needs a framing 
mechanism applicable to both RTP and non-RTP traffic.

thanks,
-rohan

On Dec 12, 2006, at 3:18, Thomas LEVY wrote:
> Thus, i am just wondering if  - when defining the framing for STUN - 
> you considered using the framing defined in rfc4571?
> in draft-ietf-behave-turn-02. I think it introduces a complexity to 
> RTP that shouldn't be aware of it
> Furthermore, my "own personal developer experience" makes me think 
> that it would be easier to functionally separate framing from protocol

---

From: Thomas LEVY <[email-masked]>
Date: Tue, 12 Dec 2006 17:49:09 +0100

Hi Rohan,

The framing defined in rfc4571 (i.e: "having a 16-bit unsigned integer 
LENGTH field" before the data) doesn't sound specific to me.
I don't see why it couldn't be applied to STUN or any other traffic?

Thomas

Rohan Mahy a écrit :

>> I have a question related to the framing mechanism for 
>> stream-oriented transports defined in draft-ietf-behave-turn-02.
>> Furthermore, RTP already specified a framing mechanism in rfc4571 
>> that could be applicable to STUN.
>> On my opinion, i would be favorable to using the same framing for 
>> STUN and RTP.
>> sends its media through a relay (TURN) it must use the framing 
>> defined in draft-ietf-behave-turn-02. I think it introduces a 
>> complexity to RTP that shouldn't be aware of it
>> that it would be easier to functionally separate framing from 
>> protocol identification for the better design of a protocol stack.
>>
>> Thomas
>
>

---

From: "Rohan Mahy" <[email-masked]>
Date: Tue, 12 Dec 2006 16:16:08 -0800

Hi,

Perhaps some use cases would help.  All of these examples assume that
the Active Destination is set to the peer:

1. RTP over UDP (no TURN)
RTP header
RTP payload

2. RTP over TCP (no TURN)
Length=(length of RTP header+payload)
RTP header
RTP payload

3. TURN Allocation over TCP to a peer running RTP over UDP
TURN TCP framing -- Type=Data, Length=(length of RTP header+payload)
RTP header
RTP payload

4. TURN Allocation over TCP to a peer running STUN/ICE over UDP
TURN TCP framing -- Type=Data, Length=(length of peer-destined STUN message)
STUN message

5. Control message about TURN Allocation over TCP
TURN TCP framing -- Type=STUN, Length=(length of STUN control message)
STUN message

6. TURN Allocation over TCP to a peer running SIP over UDP
TURN TCP framing -- Type=Data, Length=(length of SIP message)
SIP message

7. TURN Allocation over TCP to a peer running syslog over TCP
TURN TCP framing -- Type=Data, Length=(arbitrary length to the end of
data segment)
some syslog stream data

8. TURN Allocation over TCP to a peer running RTP over TCP
TURN TCP framing -- Type=Data, Length=(length of RTP header+payload + 2)
RTP over TCP framing -- Length=(length of RTP header+payload)
RTP header
RTP payload

A. Even if we decided to copy the same kind of framing used for RTP
over TCP, we would still need to repeat the RTP over TCP framing when
delivering to the peer (note the difference between #3 and #8). In
other words, TURN relays arbitrary end-to-end data; it does not
specially relay RTP from TCP to UDP.

B. Since we need some framing only for consumption between the TURN
client and the relay, it is a good idea for us to include the Type
indicator so we can more easily distinguish between case #4 and #5.

thanks,
-rohan

---

From: "Mayank Dev Sondhi" <[email-masked]>
Date: Wed, 13 Dec 2006 09:45:34 +0530

Please excuse my discussion of an implementation specific scenario, but I
believe it is pertinent.

One of the advantages I can cite(having developed a particular
implementation of the STUN/TURN relay) is that over TCP it is always
advantageous to separate out control messages over normal data messages. We
faced a problem wherein we had to implement some policing of the bandwidth,
and we did this in the simplest and naive way by not doing recvs on our
sockets if b/w was exceeded. Unfortunately control messages for cancellation
of the operation would also get queued up with the net effect that a user
cancel operation would also get stuck on the recv queue of the socket.

If there was a framing mechanism that allowed us to distinguish this we
could very easily separate out signalling from transfer in our stack without
sacrificing on performance. I think this design helps us in that regard by
including the type in the frame itself.

Thanks
Mayank

---

From: Thomas LEVY <[email-masked]>
Date: Thu, 14 Dec 2006 09:40:04 +0100

Hello Mayank

Do you mean you would like to have the STUN traffic and the data traffic 
sperated in order to do separate "socket recv"?
I believe the only way to do this would be to have 2 sockets (one for 
the traffic and one for the control) but this is not in line with the 
logic of TURN.

Thomas

Mayank Dev Sondhi a écrit :

> Please excuse my discussion of an implementation specific scenario, 
> but I believe it is pertinent.
>  
> advantageous to separate out control messages over normal data 
> messages. We faced a problem wherein we had to implement some policing 
> of the bandwidth, and we did this in the simplest and naive way by not 
> doing recvs on our sockets if b/w was exceeded. Unfortunately control 
> messages for cancellation of the operation would also get queued up 
> with the net effect that a user cancel operation would also get stuck 
> on the recv queue of the socket.
>
> If there was a framing mechanism that allowed us to distinguish this 
> we could very easily separate out signalling from transfer in our 
> stack without sacrificing on performance. I think this design helps us 
> in that regard by including the type in the frame itself.
>  
> Thanks
> Mayank
>  
> From [email-masked] Thu Dec 14 03:40:40 2006
Date: Thu, 14 Dec 2006 09:40:04 +0100
From: Thomas LEVY <[email-masked]>
To: Mayank Dev Sondhi <[email-masked]>
Subject: Re: [BEHAVE] Re: STUN/TURN framing or RTP framing
Cc: Rohan Mahy <[email-masked]>, [email-masked], [email-masked]

Hello Mayank

Do you mean you would like to have the STUN traffic and the data traffic 
sperated in order to do separate "socket recv"?
I believe the only way to do this would be to have 2 sockets (one for 
the traffic and one for the control) but this is not in line with the 
logic of TURN.

Thomas

Mayank Dev Sondhi a écrit :

> Please excuse my discussion of an implementation specific scenario, 
> but I believe it is pertinent.
>  
> advantageous to separate out control messages over normal data 
> messages. We faced a problem wherein we had to implement some policing 
> of the bandwidth, and we did this in the simplest and naive way by not 
> doing recvs on our sockets if b/w was exceeded. Unfortunately control 
> messages for cancellation of the operation would also get queued up 
> with the net effect that a user cancel operation would also get stuck 
> on the recv queue of the socket.
>
> If there was a framing mechanism that allowed us to distinguish this 
> we could very easily separate out signalling from transfer in our 
> stack without sacrificing on performance. I think this design helps us 
> in that regard by including the type in the frame itself.
>  
> Thanks
> Mayank
>  
> On 12/13/06, *Rohan Mahy* <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     On 12/12/06, Thomas LEVY <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     > Hi Rohan,
>     >
>     > >> An other method for protocol identification ( i.e: to
>     distinguish STUN
>     > >> On my opinion, i would be favorable to using the same framing forOn 12/13/06, *Rohan Mahy* <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     On 12/12/06, Thomas LEVY <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     > Hi Rohan,
>     >
>     > >> An other method for protocol identification ( i.e: to
>     distinguish STUN
>     > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Thomas LEVY <[email-masked]>
Date: Thu, 14 Dec 2006 09:39:54 +0100

---

From: Thomas LEVY <[email-masked]>
Date: Thu, 14 Dec 2006 09:39:54 +0100

Hi Rohan,

You talk about the need to separate (for inst: at the STUN/TURN server 
level) the data packets from the STUN/control packets.
It is also what I called protocol identifiation in my first mail.
This need is the same for UDP packets than for TCP packets.
stun-bis specifies to use the magic cookie for that purpose. This is 
true for UDP and for TCP.
Why is there a need to add a new mechanism for TCP (such as: a specific 
framing) instead of the existing mechanism in stun-bis?

Thomas

Rohan Mahy a écrit :

>> >> On my opinion, i would be favorable to using the same frt=subscribe>
Errors-To: [email-masked]

Hi Rohan,

You talk about the need to separate (for inst: at the STUN/TURN server 
level) the data packets from the STUN/control packets.
It is also what I called protocol identifiation in my first mail.
This need is the same for UDP packets than for TCP packets.
stun-bis specifies to use the magic cookie for that purpose. This is 
true for UDP and for TCP.
Why is there a need to add a new mechanism for TCP (such as: a specific 
framing) instead of the existing mechanism in stun-bis?

Thomas

aming for

---

From: "Rohan Mahy" <[email-masked]>
Date: Fri, 15 Dec 2006 17:59:30 -0800

Hi Thomas,

For UDP there are STUN packets addressed to/from the TURN relay and
STUN packets address to/from the peer.  The STUN packets addressed to
or from the peer need to be wrapped in Send or Data indications, even
if the peer is the active destination.

The TCP framing could use the same approach, but we chose not to
require this extra step.  By including a type, the distinction between
end-to-end data to the active destination and other messages is
clearer. We could have decided to add this same type header to UDP,
but then MTU-sized datagrams to the active destination would be
unnecessarily fragmented.

I hope this thread has provided you with some of the design
motivations used, even if you do not agree with the specific
trade-offs. For now, we have consensus to use the framing in the
current document and no technical reason to make a change.

thanks,
-rohan

---

From: "Frank W. Miller" <[email-masked]>
Date: Mon, 18 Dec 2006 15:08:47 -0700

Interesting link...

http://www.heise-security.co.uk/articles/82481

FM

---

From: "Mayank Dev Sondhi" <[email-masked]>
Date: Tue, 19 Dec 2006 12:24:58 +0530

mmm, no not exactly. I was highlighting a particular implementation problem
that we forced ourselves into where separating out STUN from normal DATA
traffic would be advantageous.

Most protocols tend to separate signalling from the actual transmission of
data, and this is a good thing. However in certain trivial protocols, if
implementers can live with extra packet processing, it is good to also
include this bifurcation in a "relaying" protocol like STUN(or actually
TURN). Thus my implementation if it so desires can and should be easily able
to support me able to differentiate between control and data packets. Of
course packets in a TCP sense are somewhat meaningless because of the
streaming nature of the protocol itself.

I used the example to bolster the case for not having a "MAGIC COOKIE"
scenario for TCP. I am in agreement with you that the current framing design
for TCP STUN messages is better.

Regards
Mayank

PS: Bad time to be in Seattle, power outages had me stranded high and
dry..well not so dry!

On 12/14/06, Thomas LEVY <[email-masked]> wrote:
> > <mailto: [email-masked]>> wrote:
> >
> >     Hi,
> >
> >     On 12/12/06, Thomas LEVY < [email-masked]
> >     > The framing defined in rfc4571 ( i.e: "having a 16-bit unsigned
> >     integer

---

From: [email-masked]
Date: Tue, 19 Dec 2006 12:18:12 +0100

Hi Rohan,

Thanks for your explanations, I was still thinking about the 
DESTINATION-ADDRESS attribute defined previously in turn that seemed to 
avoid wrapping.
I now understand better the motivation for the TCP framing.
It introduces an optimization for TCP in comparision to UDP (to avoid 
wrapping STUN packets in STUN packets).

Thomas

---

From: "Brian Stucker" <[email-masked]>
Date: Tue, 19 Dec 2006 16:35:23 -0600

Bifurcation of media and signaling, where both are handled by the same network element causes a doubling (or more) of the number of ports required to support a particular data flow. This doubles (or more) the cost of deploying a TURN server into a network.
 
Also, given that TURN is being used to relay around NATs, and the recent discussions around the benefits of multiplexing RTCP and RTP over the same connection because of NAT complications, it seems like it would be tricky to justify why it's 'a good thing' (tm) to multiplex the media and the media signaling (RTCP+RTP) but not the media/media signaling and the TURN signaling.
 
Regards,
Brian

________________________________

	From: Mayank Dev Sondhi [mailto:[email-masked]] 
	Sent: Tuesday, December 19, 2006 12:55 AM
	To: Thomas LEVY
	Cc: Rohan Mahy; [email-masked]; [email-masked]
	Subject: Re: [BEHAVE] Re: STUN/TURN framing or RTP framing

	mmm, no not exactly. I was highlighting a particular implementation problem that we forced ourselves into where separating out STUN from normal DATA traffic would be advantageous.
	 
	Most protocols tend to separate signalling from the actual transmission of data, and this is a good thing. However in certain trivial protocols, if implementers can live with extra packet processing, it is good to also include this bifurcation in a "relaying" protocol like STUN(or actually TURN). Thus my implementation if it so desires can and should be easily able to support me able to differentiate between control and data packets. Of course packets in a TCP sense are somewhat meaningless because of the streaming nature of the protocol itself. 
	 
	I used the example to bolster the case for not having a "MAGIC COOKIE" scenario for TCP. I am in agreement with you that the current framing design for TCP STUN messages is better.
	 
	Regards
	Mayank
	 
	PS: Bad time to be in Seattle, power outages had me stranded high and dry..well not so dry!

	On 12/14/06, Thomas LEVY <[email-masked] > wrote: 

		Hello Mayank

		Thomas
		
		Mayank Dev Sondhi a écrit :
		
		> On 12/13/06, *Rohan Mahy* < [email-masked] <mailto:[email-masked]> 
		>     On 12/12/06, Thomas LEVY < [email-masked] <mailto:[email-masked]> 
		>     > [email-masked] <mailto: [email-masked] <mailto:[email-masked]> >

---

From: "David Barrett" <[email-masked]>
Date: Tue, 19 Dec 2006 14:45:27 -0800

I agree with Brian.  In my experience, it’s vastly preferable to multiplex
everything over a single flow because in a NAT-traversing environment,
establishing that flow is very expensive and difficult.

-david 

  _____  

From: Brian Stucker [mailto:[email-masked]] 
Sent: Tuesday, December 19, 2006 2:35 PM
To: Mayank Dev Sondhi; Thomas LEVY
Cc: Rohan Mahy; [email-masked]; [email-masked]
Subject: RE: [BEHAVE] Re: STUN/TURN framing or RTP framing

Bifurcation of media and signaling, where both are handled by the same
network element causes a doubling (or more) of the number of ports required
to support a particular data flow. This doubles (or more) the cost of
deploying a TURN server into a network.

Also, given that TURN is being used to relay around NATs, and the recent
discussions around the benefits of multiplexing RTCP and RTP over the same
connection because of NAT complications, it seems like it would be tricky to
justify why it's 'a good thing' (tm) to multiplex the media and the media
signaling (RTCP+RTP) but not the media/media signaling and the TURN
signaling.

Regards,

Brian

  _____  

Regards

Mayank

On 12/14/06, Thomas LEVY <[email-masked]
<mailto:[email-masked]> > wrote: 

Hello Mayank

Thomas

>     On 12/12/06, Thomas LEVY < <mailto:[email-masked]>
[email-masked]