Subject: [tram] SSODA (Single SOcket Dual Allocation with TURN)

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Mon, 17 Mar 2014 10:55:28 +0000

Hi TRAMsters,

Justin, Oleg and myself wrote up some of the thoughts regarding single socket dual IPv4/IPv6 allocations that was discussed earlier on the list. There are still open issues, but we feel it is important that the discussion continue on the list.

Below are the submission details:

A new version of I-D, draft-martinsen-tram-ssoda-00.txt
has been successfully submitted by Paal-Erik Martinsen and posted to the
IETF repository.

Name: draft-martinsen-tram-ssoda
Revision: 00
Title: Single SOcket Dual Allocation with TURN
Document date: 2014-03-17
Group: Individual Submission
Pages: 8
URL:            http://www.ietf.org/internet-drafts/draft-martinsen-tram-ssoda-00.txt
Status:         https://datatracker.ietf.org/doc/draft-martinsen-tram-ssoda/
Htmlized:       http://tools.ietf.org/html/draft-martinsen-tram-ssoda-00

Abstract:
  This draft describes a simple method for allocating one IPv4 and one
  IPv6 relay address from a single ALLOCATE request to the TURN server.
  This saves local ports on the client, reduces the number of
  candidates gathered by the client, and reduces the number of messages
  sent between the client and the TURN server.

.-.
Pål-Erik

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 19 Mar 2014 06:22:05 +0000

Please see inline

> -----Original Message-----
> From: tram [mailto:[email-masked]] On Behalf Of Simon Perreault
> Sent: Tuesday, March 18, 2014 8:06 PM
> To: [email-masked]
> Subject: Re: [tram] SSODA (Single SOcket Dual Allocation with TURN)
> 
> Le 2014-03-18 06:13, Tirumaleswar Reddy (tireddy) a écrit :
> > My initial comments
> >
> > 1) Introduction
> >
> > Secondly,  with fewer local host ports there will be fewer NAT bindings for the
> NAT to keep track of, and fewer server reflexive candidates.
> >
> > Comment>
> > This benefits IPv4 only hosts and the above sentence may not be applicable for
> dual-stack hosts.  With IPv6 there will no NAT or even with NPTv6 it's just 1:1
> mapping.
> 
> The statement would also apply to IPv6 hosts behind stateful IPv6
> firewalls. I, for one, am behind such a firewall at work (actually two
> layers of stateful IPv6 firewalls).

Good point.  

> 
> And NAT64...
> 
> > Dual-stack host let's say behind both NAT44 and NPTv6, cannot use single
> ALLOCATE request to learn both relayed and server-reflexive addresses for both
> families.
> 
> This is true, but if I'm not mistaken, and please correct me if I'm
> wrong, in ICE you can not use a single TURN connection for creating both
> a server-reflexive and a relayed candidate. 

It's explained in section 2.1 of RFC 5245 http://tools.ietf.org/html/rfc5245#section-2.1 with an example that single TURN allocate request can be used by ICE agent 
to learn both sever-reflexive and relayed candidates.

> Each candidate needs its own
> socket. If that is correct then SSODA is no worse and no better than the
> status quo in this regard.
> 
> > Additional details when client should use this mechanism will be helpful.
> >
> > 2)  If the Allocate Response contains only one XOR-RELAYED-ADDRESS
> >    attribute, then the client knows that the TURN server does not
> >    support SSODA.  The client can retry the missing address family
> >    allocations on new 5-tuples, if desired.  Subsequent Allocate
> >    requests towards the same TURN server SHOULD NOT include multiple
> >    REQUESTED-ADDRESS-FAMILY attributes
> >
> > Comment>
> > How will the client ever know that the server has upgraded and now supports
> the new mechanism proposed in the draft ?
> > May be the client once in a day can probe and find if the server supports
> multiple REQUESTED-ADDRESS-FAMILY attributes in a single ALLOCATE request.
> 
> Good observation. IMHO that last sentence is not necessary for
> interoperability. Let client implementers figure it out.

Yup, last line can also be removed.

> 
> > 4) How does this mechanism reduce the number of candidates gathered during
> the discovery process ?
> 
> It does not. That's not the goal. The goal is being able to obtain two
> candidates (IPv4 and IPv6 relayed candidates) using a single socket.

Agreed. But Introduction needs to be fixed to remove the following line
"reduce the number of candidates gathered during the discovery process"

Cheers,
-Tiru

> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram