Subject: [BEHAVE] General consensus on a UDP shim for TURN

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 16 Oct 2007 16:17:48 -0400

The TURN editing team is anxious to start making changes to TURN. The 
big thing we need to get group consensus on is this: Is there general 
consensus around adding some kind of shim (we can debate 8 vs. 32 bits) 
for UDP, for the purposes of adding a channel concept so we can remove 
the active destination functionality from the spec?

Please weigh in.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

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

---

From: "Derek MacDonald" <[email-masked]>
Date: Wed, 17 Oct 2007 01:20:14 -0700

I prefer the channel approach over the active destination approach mainly
for aesthetic reasons. AD always seemed like a bit of a hack and required
lots of jumping through hoops when forking happened, but it wasn't too hard
to hide from the user of our turn library.

That said, I think we need to keep the shim as light as possible; I have
seen deployments where there is very little headroom in the UDP packets--~20
bytes.  It's possible to optimize down to th bone when you have prediictable
uris(numeric, 10 digit) and record routes(IP addrs) in your network. 8 bits
sounds good:)
-Derek

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 17 Oct 2007 07:18:38 -0700

> the active destination functionality from the spec?

I like the channel proposal.  This is simpler to implement than the
active destination stuff and also remove the problem of having to choose
what destination is the active one.  I already wrote some basic code
implementing this, and didn't find any issue yet.

I support using 16 bits for the channel #, and no length field.  I fell
better with 65535 channels available in each direction than 255, knowing
that channels # cannot be reused.

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

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Thu, 18 Oct 2007 09:07:56 +0300

> the active destination functionality from the spec?

I tend to prefer fixed size "overhead" (whatever the size), but I won't whine 
if the SAD approach is maintained.

But I really do NOT want to have both options in the protocol.

-- 
Rémi Denis-Courmont