Re: [tram] IPv4 and IPv6 allocations

If we allow two allocations per session that would be unnecessary
complication that does not serve any immediate purpose that cannot be
served in another way and it would encourage waste of resources. I do not
think that would be a good idea.

Oleg

On Wed, Feb 19, 2014 at 8:44 AM, Simon Perreault <
simon.perreault@viagenie.ca> wrote:

> Le 2014-02-19 11:37, Pal Martinsen (palmarti) a écrit :
> > IMHO this would make a good optimisation. Endpoints can discover how
> > to reach the TURN server well before a call is made, webRTC is a bit
> > more tricky but Ill guess there are room for some sort of "pre call"
> > discovery there as well. The agent can thus lock down to a specific
> > IP address family talking to the TURN server. To further reduce
> > chatter it would be nice to be able to allocate two types of IP
> > RELAY addresses with one allocation message. Writing up draft
> > describing that would not be to hard unless I miss something.
>
> I think it would be super hard, as in it would require completely
> redesigning TURN. :)
>
> All the TURN messages rely on there being a single allocation per
> 5-tuple. For example, in a Send indication, you don't tell the server
> out of which allocation (i.e., external port) to send the actual packet.
> So you would need to add an "allocation ID" attribute to just about
> everything: Send, Data, Refresh, etc. Then we need to think about
> channels. By this point we are fairly discouraged, and we still need to
> think about TURN-TCP. Yuck.
>
> One allocation per 5-tuple. I don't think we're changing this anytime soon.
>
> Simon
> --
> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
> NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
> STUN/TURN server               --> http://numb.viagenie.ca
>
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram
>