Subject: Re: [BEHAVE] TURN Issue #6: Framing header for actual TURN messages

From: Philip Matthews <[email-masked]>
Date: Fri, 4 Jan 2008 17:17:24 -0500

During the conference call on Dec 20, we agreed to remove the TURN  
framing header before TURN control messages.

To allow the maximum number of channels, I would like to propose that  
TURN control messages be identified as having the leading two bits be  
"00", as is typically done with STUN messages. This leaves the other  
combination of bits for channel numbers.

That is, if the first two bits are:
   00   -  TURN control message
   01   -  TURN data packet
   10   -  TURN data packet
   11   -  TURN data packet

This means that channel numbers would run from 0x4000 to 0xFFFF, with  
0xFFFF being a reserved channel number. This gives 49151 different  
channels.

Comments?

- Philip

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

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 7 Jan 2008 09:31:31 +0200

> 0xFFFF being a reserved channel number. This gives 49151 different

As was pointed out in the telco, I think the difference between 0x7fff and 
0xbfff is not significant here, as these quantities are of the same order of 
magnitude. On the other hand, testing two bits ((buf[0] >> 6) == 0) instead 
of just one ((buf[0] >> 7) == 0) is also totally insignificant a change.

As such, I would like to stay neutral on this question :)

-- 
Rémi Denis-Courmont

---

From: Philip Matthews <[email-masked]>
Date: Tue, 8 Jan 2008 03:24:33 -0500

Some of the motivation for this proposal comes from the fact that  
testing that the first two bits are 00 is something that STUN already  
does.
- Philip

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 8 Jan 2008 20:40:53 -0800

On Jan 4, 2008, at 2:17 PM, Philip Matthews wrote:

> This means that channel numbers would run from 0x4000 to 0xFFFF,  
> with 0xFFFF being a reserved channel number. This gives 49151  
> different channels.
>
> Comments?

No one has ever explained to me why we need more than 200 channels.

Cullen <with my individual hat on>

---

From: "Derek MacDonald" <[email-masked]>
Date: Wed, 9 Jan 2008 17:06:14 -0800

No channel re-use, so lots of channels allows long lived allocations.

32768 is plenty for me(and was antural from a protocol persepctive),
and it makes the 1 byte read from TCP case easy.

-Derek

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 9 Jan 2008 18:53:59 -0800

RIght, but I am missing the need for an allocation that is longer  
lived than 200 connections given how easy it is to get a new  
allocation. I'm pushing on the "why" for this because the only use  
cases I could imagine require us to do things that seem somewhat  
problematic.

(as a side issue, I suspect we are going to end up needing a close  
command for channels to get the ICMP error to behave correctly which  
would then allow channel reuse but that is totally a side issue - the  
current issue is I don't understand the need for more than 200 channels)

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 18 Jan 2008 16:32:13 +0100

Hi,

Sorry for being this late in commenting on this. However, I wonder if 
you are recreating a issue STUN was designed to avoid or not. These two 
bits in STUN is 00 to avoid matching RTP. Thus, with the proposed 
definition it is important that one never tries to multiplex TURN and 
RTP on the same local port.

I got worried as someone thought this change would allow running STUN 
and TURN on the same local port. This implied for me that also RTP would 
be used on this same port. I think it is important to point out that 
TURNs thin encapsulation does not support enough mechanisms to detect 
protocol collisions to allow multiplexing protocols on the same port.

Cheers

Magnus

-- 

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Philip Matthews <[email-masked]>
Date: Fri, 18 Jan 2008 10:45:06 -0500

On 18-Jan-08, at 10:32 , Magnus Westerlund wrote:

> Hi,
>
> Sorry for being this late in commenting on this. However, I wonder  
> if you are recreating a issue STUN was designed to avoid or not.  
> These two bits in STUN is 00 to avoid matching RTP. Thus, with the  
> proposed definition it is important that one never tries to  
> multiplex TURN and RTP on the same local port.

I don't foresee any need to multiplex TURN and RTP. However, I do  
foresee carrying RTP inside TURN messages.

>
> I got worried as someone thought this change would allow running  
> STUN and TURN on the same local port.

The change to remove the framing header from TURN message _would_  
allow STUN and TURN to run on the same port. Recall that TURN is just  
an extension to STUN, so this is a pretty natural thing to do. In  
fact, the TURN Allocate Response message also carries the XOR-MAPPED- 
ADDRESS attribute, so there is no need to a Binding transaction if  
you do an Allocate transaction.

> This implied for me that also RTP would be used on this same port.
No.
I don't see any need right now to multiplex TURN with any other  
protocol (other than STUN, which isn't really a multiplexing situation).

> I think it is important to point out that TURNs thin encapsulation  
> does not support enough mechanisms to detect protocol collisions to  
> allow multiplexing protocols on the same port.

I agree. We would have to give up a portion of the channel number  
space to make multiplexing possible, if this was needed. But as I  
said, I don't see a need for it right now.

- Philip

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 18 Jan 2008 17:24:15 +0100

Okay,

As long as this is clear. I think it will be required to point this out 
as STUN is possible to multiplex with RTP.

Cheers

Magnus

Philip Matthews skrev:
>> you are recreating a issue STUN was designed to avoid or not. These 
>> two bits in STUN is 00 to avoid matching RTP. Thus, with the proposed 
>> and TURN on the same local port.
> 
> The change to remove the framing header from TURN message _would_ allow 
> STUN and TURN to run on the same port. Recall that TURN is just an 
> extension to STUN, so this is a pretty natural thing to do. In fact, the 
> TURN Allocate Response message also carries the XOR-MAPPED-ADDRESS 
> attribute, so there is no need to a Binding transaction if you do an 
> Allocate transaction.
> 
> 
> 
> I don't see any need right now to multiplex TURN with any other protocol 
> (other than STUN, which isn't really a multiplexing situation).
> 
> I agree. We would have to give up a portion of the channel number space 
> to make multiplexing possible, if this was needed. But as I said, I 
> don't see a need for it right now.
> 
> 
> - Philip
> 

-- 

Magnus Westerlund

---

From: Philip Matthews <[email-masked]>
Date: Fri, 18 Jan 2008 12:42:30 -0500

Let me summarize what I believe is the current state of this issue.

We have agreed that TURN control messages will _not_ use the framing  
header. Separately, we have also agreed to use EKRs mechanism to  
allocate channels. The combination of these two means that the  
"framing header" is only used for application data traveling on a  
channel. What this really means is that we have a new non-STUN- 
formatted message that carries application data. I am proposing to  
call this message a "ChannelData" message.

So the point we are discussing now is how to distinguish a  
ChannelData message from a STUN-formatted message. Here the original  
proposal was to use the first bit of the message to distinguish the  
two: a STUN-formatted message has the first bit set to 0, and the  
ChannelData message has the first bit set to 1.

My proposal is to instead use the first two bits. My reasoning is  
that the first two bits of a STUN message are always '00' and all  
other combinations can be used for the ChannelData message. To be  
precise, here is the text that I am proposing:

    The ChannelData message is used to carry application data between  
the
    client and the server.  It has the following format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Channel Number        |            Length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    /                       Application Data                        /
    /                                                               /
    |                                                               |
    |                               +-------------------------------+
    |                               |
    +-------------------------------+

    The Channel Number field specifies the number of the channel on  
which
    the data is traveling, and thus the address of the peer that is
    sending or is to receive the data.  The channel number MUST be in  
the
    range 0x4000 - 0xFFFF, with channel number 0xFFFF being reserved for
    possible future extensions.

    Channel numbers 0x0000 - 0x3FFF cannot be used because bits 0 and 1
    are used to distinguish ChannelData messages from STUN-formatted
    messages (i.e., Allocate, Send, Data, ChannelBind, etc).  STUN-
    formatted messages always have bits 0 and 1 as "00", while
    ChannelData messages use combinations "01", "10", and "11".

In discussing how to distinguish ChannelData messages from STUN- 
formatted messages, the following issues have been raised:
* (Derek) It is easier to look at just one bit, rather than two bits.
* (Cullen) How many channels do we need anyway? Why do we need more  
than 200 channels?

In addition, there is the question of whether we need a way to de- 
allocate channels. During the conf call of 20 Dec, there was  
agreement amongst the participants that such a mechanism was  
required, but so far no mechanism has been proposed yet.

Right now, my intention is to put the above text into TURN-06 and  
then flag three open issues:
1) What is the exact format of the ChannelData message?
2) How many channels do we need?
3) Do we need a mechanism to release channels, and if so, what does  
it look like?

My personal opinion on #3 is now leaning to "YES", but I haven't had  
a chance to propose a mechanism yet.

Comments?

- Philip

---

From: "Rohan Mahy" <[email-masked]>
Date: Sat, 26 Jan 2008 16:08:14 -0800

I have watched this discussion for the last several weeks, fully expecting
for sanity to reassert itself at some point in the discussion.

I think it is wholly inappropriate to revisit this framing issue again.  We
had a very strong consensus at a previous meeting and on the mailing list
that we were going to apply framing to every message. In fact we agreed that
the framing length on UDP would be the actual length. This framing was added
and we agreed at the adhoc and shortly thereafter on the list to use EKR's
proposed ChannelBinding approach to associate non-zero channel numbers with
a peer WITH the framing on every message.  Then, on a phone call (on Dec
20th), the folks on the call decided to reopen a design decision that had no
associated open issue and no technical problem associated with it.
The supposed benefits of running without framing are not new and were
mentioned explicitly the last time we went over this issue and we decided
that they were pretty weak.  1) Running STUN and TURN on the same port:
nobody cared, 3) Might make people more aware that TURN is an extension of
STUN: this is philisophical wanking of the highest degree--WHO CARES!, 2)
Ditching framing saves 4-bytes: This was the crux of the discussion and we
decided the simplicity and determinism of using consistent framing was far
more important than 4 octets when using UDP (recall that we always need this
framing over TCP).

Applying framing to every message consistently makes the protocol and its
implementations simpler. When I rewrote TURN to use consistent framing, I
was amazed at how much simpler the protocol was to explain in the spec and
after speaking to several implementors, the feedback I received was very
consistent. Consistent framing was easier to implement, resulted in fewer
corner cases and resulted in code that was easier to understand and
maintain.
While I don't care how many bits we use to represent a channel number, I
strongly suggest we go back to framing every TURN message.

thanks,
-rohan

On Dec 7, 2007 3:04 PM, Jonathan Rosenberg <[email-masked]> wrote:

> This issue was not in my slides. It was brought up at the mike in the
> WG, and was discussed there. It was not discussed further at the ad-hoc.
>
> As of turn-05, we introduced a framing mechanism, which is a 4 byte
> header consisting of 2 bytes channel and 2-bytes length. This framing
> header precedes ALL packets sent between a client and its TURN server,
> including both application data and TURN messages themselves, which are
> sent on channel zero.
>
> Ekr raised a question of why this header was needed for actual TURN
> messages. After all, he argued, we went through all this trouble to make
> STUN (and thus TURN) differentiatable from each other. Indeed, others
> noted that the framing header itself looks very similar to the top 4
> bytes of the STUN message format anyway:
>
>         0                   1                   2                   3
>        |0 0|     STUN Message Type     |         Message Length        |
>        |                         Magic Cookie                          |
>        |                     Transaction ID (96 bits)                  |
>        |                                                               |
> and the proposed framing header:
>
>         0                   1                   2                   3
>        |        Channel                |         Message Length        |
> So an alternative design is to make the framing header look like:
>
>
>         0                   1                   2                   3
>        |1|      Channel                |         Message Length        |
> So that there are 15 bits of channel instead of 16. Placing a 1 in that
> position makes the framing header always a non-match for STUN messages.
> Thus, it would not be even needed to do the more complex matching
> operations defined in STUN; a 1-bit check would do the job to separate
> out application data from STUN/TURN.
>
> The benefits of this change would be:
>
>   1. We would, once again, be able to run STUN and TURN on the same
> port on the server. As of turn-05 they MUST run on different ports
> because the framing header was unique to TURN. This could be a feature
> or a bug depending on your perspective:
>
>          FEATURE: TURN and STUN are actually very different; using
> separate ports would allow a firewall to block one and not the other.
>
>          BUG: practically speaking separate ports doesnt help since
> with DNS the ports can be dynamic anyway. In addition, its always good
> to use fewer ports on a server. Also its weird that an extension to a
> protocol would run on a different port; that kind of tells you its not
> an extension.
>
>   2. Reduces the size of TURN messages by 4 bytes. This is a minor
> benefit and the real one is having a single port.
>
>   3. it'd be a little clearer to explain to people that TURN is an
> extension to STUN, rather than saying, TURN is a STUN extension that is
> run over a new framing header
>
> The drawbacks of this change would be:
>
>   1. cuts the number of channels in half
>
>
> An alternative design would be to use the full 16 bits for channel
> numbers, and then rely on the full suite of STUN differentiation
> techniques to demux. However, my preference in general is to not do that
> when its not actually needed. It complicates message processing and I
> don't think its worth it. 32767 channels is also a LOT for our
> envisioned use cases.
>
> This was somewhat inconclusive at the microphone. I'm personally on the
> fence and don't feel that strongly. I probably midly prefer making this
> change.
>
> Please comment on whether you prefer this change or not.

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 26 Jan 2008 19:42:55 -0800

At Sat, 26 Jan 2008 16:08:14 -0800,
Rohan Mahy wrote:
> that we were going to apply framing to every message.

Hmm.. I definitely remember some discussion of framing everything
(Prague, right?) but I don't remember the implication being that STUN
would framed, but rather that all other protocols would
need to be framed.

> In fact we agreed that
> a peer WITH the framing on every message. 

I definitely don't remember that from the ad hoc.

> Then, on a phone call (on Dec

Hmm TURN-04 had framing (though it was different) for stream
transports but as I read the spec, STUN over UDP was un-framed.  I'm
not sure I would characterize discussing a design decision that first
appeared in TURN-05 (in YVR) as "reopening it". This is a new design.
I don't think it's the best one.

> nobody cared,

I care.

> 3) Might make people more aware that TURN is an extension of

Well, the 4 bytes wasn't *my* reason. Rather, I think that having a lot
of different ways to demux STUN from other things is architecturally
inelegant. And since as Cullen observed, it's possible to disambiguate
them from the initial bytes, I don't see the value of having yet
another piece of demuxing. Moreover, it makes writing a combined
STUN/TURN stack modestly easier, IMO.

> implementations simpler.

Well, I guess this is a matter of opinion: I'm an implementor and I don't
think that it makes that it makes the implementation simpler. On the
contrary, I think it makes it more complicated.

-Ekr

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 27 Jan 2008 07:02:23 -0800

> contrary, I think it makes it more complicated.

I now implemented both versions of the framing on a TURN client, TURN
server and on a Wireshark dissector (Alice, Bob and Eve :-).  The
implementation difference between the two framings is minimal in the
client and the server side.  For the Wireshark dissector with the
TURN-05 framing, TURN is decoded as a separate protocol and so need a
separate dissector.  With the TURN-06 framing, TURN is decoded as STUN
protocol and so use the same dissector.  This is the only real
difference in my opinion: With TURN-05 the protocol can be explicitly
decoded as TURN, with TURN-06 it is decoded as STUN and you have to look
closer to find that the TURN extension is used.  This said, I still have
a small preference for the TURN-06 framing.

-- 
Marc Petit-Huguenin           [                                 ]
Home: [email-masked] [RFC1855-compliant space for rent ]
Work: [email-masked]            [                                 ]
[                                                               ]

---

From: "Rohan Mahy" <[email-masked]>
Date: Sun, 27 Jan 2008 22:22:03 -0800

Eric,

Two clarifying questions:

Have you implemented both framing styles (pre-05 and 05)?

Can you please explain why you care about running some STUN usage and the
TURN protocol on the same port?  Do you have a practical use case that is
enabled that is important to you?

thanks,
-rohan

---

From: Philip Matthews <[email-masked]>
Date: Mon, 28 Jan 2008 09:16:56 -0500

I definitely remember the issue being raised at the group meeting in  
Vancouver. I also think it was discussed in the adhoc (but I may be  
wrong).

It was definitely raised on the list by Jonathan and debated in the  
weeks before the conf call on 20 Dec. On Dec 20, it was discussed and  
agreed that the framing would not be used for STUN-formatted  
messages. I recall this well, because I was originally wanted to keep  
things as they were in TURN-05 and Derek was trying to convince me  
that he really wanted it to not use framing on STUN-formatted msgs.   
However, the group decided to not frame those msgs, and I really do  
not want to re-open this question now.

- Philip

On 26-Jan-08, at 19:08 , Rohan Mahy wrote:

> I have watched this discussion for the last several weeks, fully  
> expecting for sanity to reassert itself at some point in the  
> discussion.
>
> I think it is wholly inappropriate to revisit this framing issue  
> again.  We had a very strong consensus at a previous meeting and on  
> the mailing list that we were going to apply framing to every  
> message. In fact we agreed that the framing length on UDP would be  
> the actual length. This framing was added and we agreed at the  
> adhoc and shortly thereafter on the list to use EKR's proposed  
> ChannelBinding approach to associate non-zero channel numbers with  
> a peer WITH the framing on every message.  Then, on a phone call  
> (on Dec 20th), the folks on the call decided to reopen a design  
> decision that had no associated open issue and no technical problem  
> associated with it.
>
> The supposed benefits of running without framing are not new and  
> were mentioned explicitly the last time we went over this issue and  
> we decided that they were pretty weak.  1) Running STUN and TURN on  
> the same port: nobody cared, 3) Might make people more aware that  
> TURN is an extension of STUN: this is philisophical wanking of the  
> highest degree--WHO CARES!, 2) Ditching framing saves 4-bytes: This  
> was the crux of the discussion and we decided the simplicity and  
> determinism of using consistent framing was far more important than  
> 4 octets when using UDP (recall that we always need this framing  
> over TCP).
>
> Applying framing to every message consistently makes the protocol  
> and its implementations simpler. When I rewrote TURN to use  
> consistent framing, I was amazed at how much simpler the protocol  
> was to explain in the spec and after speaking to several  
> implementors, the feedback I received was very consistent.  
> Consistent framing was easier to implement, resulted in fewer  
> While I don't care how many bits we use to represent a channel  
> number, I strongly suggest we go back to framing every TURN message.
>
> thanks,
> -rohan
>
>
>        |                         Magic  
> Cookie                          |