[Standards] Proposed XMPP Extension: STUNServerDiscovery forJingle

Scott Ludwig scottlu at google.com
Tue Mar 27 04:26:21 UTC 2007


On 3/26/07, Thiago Camargo <thiago at jivesoftware.com> wrote:
> Here goes a suggestion:
>
> 1> the discovery mechanism (Use STUN/Media Relay Discovering suing XMPP)
>
> 2> the client does dns name resolution and choose the best relay server.

At the end of step #2, the client will have an ip address. The port is
returned for a given server in step #1.

> 3> Client ask XMPP Server to allocate a Relay Channel on the selected Relay Server. Then server returns the IP address, password and port pair.

This presents problems. The reason is how load is distributed to a
backend. For example we have a pool of relay servers behind a single
IP. There is a special server in front that handles the incoming
client request and chooses a backend to give the request to. It
remembers the binding between the client ip and the chosen backend for
some period of time so future traffic goes to the same place. This is
a common way to have a larger pool of machines servicing load behind a
single ip.

If the xmpp server were to choose the backend, there is no gaurantee
that the relay allocation would be on the same server that the
client's traffic would eventually get distributed to.

It's better if the client simply negotiates directly. Then the network
path gets established and maintained for the duration of the session.
I don't think this adds more complexity for the client, since
allocating the relay binding is straightforward even when doing it
directly.

One last point - from my point of view, the less the xmpp service has
to know about the relay service the better. That way as inevitable
changes get made to each over time, the other doesn't need to be
updated. In practice this has turned out to be a good thing.

> With this approach clients don't need to negotiate the allocation of a relay directly to a relay server.
> Clients will only have to send media to the relay server using the correct ports.
>
> It will make clients implementations much easier. And the type of the relay Server will be transparent.
>
> Regards,
> Thiago
>
>
> -----Original Message-----
> From: standards-bounces at xmpp.org [mailto:standards-bounces at xmpp.org] On Behalf Of Scott Ludwig
> Sent: segunda-feira, 26 de março de 2007 03:35
> To: XMPP Extension Discussion List
> Subject: Re: [Standards] Proposed XMPP Extension: STUNServerDiscovery forJingle
>
> > Scott,
> >
> > Is the Google approach documented anywhere? I looked at:
> >
> > http://code.google.com/apis/talk/jep_extensions/extensions.html
> >
> > but couldn't find anything about media relays.
>
> Sean will know if it is documented. If it isn't, we certainly intend
> to document it. The Google Talk client uses it as part of jingleinfo.
>
> http://code.google.com/apis/talk/jep_extensions/jingleinfo.html
>
> In addition to a stun section, there is a relay section (I notice not
> documented yet). If you watch the xmpp stream in and out of Google
> Talk.exe you can see it go by.
>
> If you look at libjingle-0.4.0, it's all in there.
>
> > Is what you're saying logically something like the following?
> >
> > C: <iq type="get">
> >      <media-relay/>
> >    </iq>
> >
> > S: <iq type="result">
> >      <media-relay>
> >        <address>example.com</address>
> >        <password>foobar</password>
> >      </media-relay>
> >    </iq>
>
> It returns a list of relay servers to try in order, listed by dns name
> and port. It also returns a token, which is good for 12 hours, signed
> with a shared secret so that the relay server can verify its
> authenticity (used when allocating a relay session). Once the client
> asks for jingleinfo the first time, the xmpp server sends a new
> jingleinfo every 6 hours, to keep the token fresh.
>
> The first server in the list is a dns name that when resolved returns
> the closest relay server for that user. The dns resolution can also be
> used for load balancing and other factors. The client simply goes
> through that list until it finds a working relay server. Most of the
> time it is the first one. By making the client robust in this way,
> taking down a data center for maintenance doesn't require special
> coordination.
>
> > Also, I'm guessing that we're going to need to define more than one media proxy type if we want to support http-based proxies officially?
>
> The Google Talk relay supports a few different candidate types: udp,
> tcp, and a special port 443 tcp candidate type. The client attempts to
> traverses https proxies using the CONNECT proxy method. Sometimes
> networks are firewalled and not proxied and only allow http and https
> traffic out. The client attempts to traverse port 443 by using a
> special candidate that negotiates ssl but then reverts to sending raw.
>
> Google Talk doesn't currently support http-only proxies. It assumes
> that for most proxied environments, if there is an http proxy, there
> is an https proxy, and it uses that. To support http proxies, media
> would need to be tunnelled in the http protocol, and that would
> require special relay support. I agree, it is worthwhile to consider.
>
> In practice this hasn't been an issue for Google Talk when it comes to
> traversal. It could be useful for web only clients.
>
> What are your thoughts on supporting http proxies (as apart from https proxies)?
>
> > Finally, why doesn't the XMPP server know the best media proxy for the user? The client always has a direct connection to the server, which means that the XMPP server knows the public IP address of the user and should be able to determine the best media relay using whatever algorithm it wants. In fact, this technique could be *much* smarter since the XMPP server could know how much traffic the media relays are getting (via trusted relationship) and do load balancing accordingly.
>
> At DNS name resolution time, many factors can be taken into account, such as:
>
> - network distance of the user
> - data center availability
> - backend availability (the relay service backend in a given data
> center for example)
> - load balancing
>
> Nowadays a company with network services of some sort that are spread
> across data centers is likely using DNS to handle some or all of these
> tasks.
>
> It's true that these things could be known by the xmpp server, however
> you'd need to build the plumbing to make this the case, and it would
> be different than mechanisms that may already be in place that use DNS
> for these tasks. This is a lot of work.
>
> Having the client do dns name resolution is the only requirement to
> use dns for these tasks. Given that dns is popularly used for these
> tasks, I suggest leveraging it, rather than banking on a custom
> solution that requires the xmpp server to have all this real time
> information.
>
> All this said, we could each use the techniques for this that we want
> transparently if we agree on:
>
> 1> the discovery mechanism (jingleinfo or something like it)
> 2> that the client does dns name resolution
> 3> how the client allocates relay sessions
>
> Then you could use your xmpp server to do load balancing / network
> distance / relay server availability if you wish. You'd simply return
> the right list of servers, in the right order, through jingleinfo. And
> those that wish to use dns for these tasks would provide their own
> list, compatible with that approach. This would work as long as
> clients performed the 3 steps above.
>
> Boiling this all down, I believe #3 is the remaining issue. At the end
> of step #2 the client has a relay server ip address, and step #3 is
> allocating a relay session from that machine. I believe you'd like to
> use xmpp. I'll point out that since at the end of step 2 there is an
> ip address, there is little need to use xmpp.
>
> >From the ICE point of view, you are free to allocate the candidates
> how you wish, xmpp or otherwise. However we need to have a documented
> method to allocate relay candidates so that a third party client, when
> encountering a new network, can successfully allocate relay
> candidates.
>
> Can we agree on the above 3 steps? Then our individual load balancing
> techniques can be used transparently to the client.
>
> Scott
>
> >
> > Regards,
> > Matt
> >
> > > -----Original Message-----
> > > From: standards-bounces at xmpp.org
> > > [mailto:standards-bounces at xmpp.org] On Behalf Of Scott Ludwig
> > > Sent: Sunday, March 25, 2007 12:07 PM
> > > To: XMPP Extension Discussion List
> > > Subject: Re: [Standards] Proposed XMPP Extension:
> > > STUNServerDiscovery forJingle
> > >
> > > The client should not allocate relay sessions via the xmpp
> > > server. It makes it difficult to scale relay load across data
> > > centers, and more difficult to choose the relay server with
> > > the lowest latency for that client.
> > >
> > > The client should discover the dns name of the relay server
> > > over XMPP, and discover an authentication token for
> > > allocating a session from the relay server, using a mechanism
> > > similar to the stun server discovery.
> > >
> > > Then the client should resolve the dns name, which will allow
> > > the client to discover the closest relay server ip address
> > > geographically, for minimal latency and good load distribution.
> > >
> > > On 3/25/07, Thiago Camargo <thiago at jivesoftware.com> wrote:
> > > > Yes, OpenFire now can act as a STUN Server, but not as a
> > > TURN Server.
> > > >
> > > > "While there are no security problems with Binding requests,
> > > > publically available TURN servers can be used by non-xmpp
> > > software as anonymous proxies."
> > > >
> > > > That's exactly what we are trying to prevent using XMPP
> > > Server to negotiate Relay Sessions for clients. In other
> > > words, clients don't have direct access to request a Relay
> > > Session from Relay Server.
> > > > User should ask a relay Session from its XMPP Server and
> > > receive everything it needs directly from XMPP Server. In
> > > this case XMPP Server should authenticate and allocate a
> > > relay session in a Relay Server, and send all the information
> > > like IP Addresses, port numbers, and password to clients.
> > > >
> > > > Regards,
> > > > Thiago
> > > >
> > > > -----Original Message-----
> > > > From: standards-bounces at xmpp.org
> > > [mailto:standards-bounces at xmpp.org]
> > > > On Behalf Of Matt Tucker
> > > > Sent: domingo, 25 de março de 2007 11:44
> > > > To: XMPP Extension Discussion List
> > > > Subject: RE: [Standards] Proposed XMPP Extension:
> > > STUNServerDiscovery
> > > > forJingle
> > > >
> > > > I didn't propose a public TURN server. Yes, that would be a
> > > crazy idea.
> > > > :) STUN is a somewhat special case because it requires two
> > > public IP
> > > > addresses from the server. Openfire can now act as a STUN
> > > server, but
> > > > the two IP address requirement makes that a bit of a setup burden.
> > > >
> > > > Regards,
> > > > Matt
> > > >
> > > > > -----Original Message-----
> > > > > From: standards-bounces at xmpp.org
> > > > > [mailto:standards-bounces at xmpp.org] On Behalf Of Evgeniy Khramtsov
> > > > > Sent: Sunday, March 25, 2007 1:47 AM
> > > > > To: XMPP Extension Discussion List
> > > > > Subject: Re: [Standards] Proposed XMPP Extension: STUN
> > > > > ServerDiscovery forJingle
> > > > >
> > > > > Matt Tucker wrotes:
> > > > >
> > > > > > * Should we run a public STUN server at xmpp.org
> > > > > >
> > > > >
> > > > > I think this is not a good idea :) While there are no security
> > > > > problems with Binding requests, publically available TURN servers
> > > > > can be used by non-xmpp software as anonymous proxies.
> > > > >
> > > >
> > >
> >
>



More information about the Standards mailing list