Subject: RE: Unique SSRC IDs?

From: "Strahm, Bill" <[email-masked]>
Date: Wed, 15 Mar 2000 08:01:45 -0800

Is your company willing to provide this service free of charge to all users
of RTP Implementations ???

By this I mean you will have to deploy a very large distributed database
around the world that anyone can connect to (how will you deal with the fact
that some conversations will happen in non-routable address spaces I do not
know).

I would expect that this service would cost your company millions of dollars
to setup and maintain over the years... Is that cheaper or writting SSRC
colision code ?

Bill

Ok, so this sounded more like a flame, just trying to point out in blunt
terms why we don't do things like this... 
______________________________________________
Bill Strahm        Programming today is a race between
bill.strahm@      software engineers striving to build
intel.com           bigger and better idiot-proof programs,
(503) 264-4632   and the Universe trying to produce
            bigger and better idiots.  So far, the
                        Universe is winning.--Rich Cook
I am not speaking for Intel.  And Intel rarely speaks for me

> -----Original Message-----
> From: Martin Mauve [mailto:[email-masked]]
> Sent: Wednesday, March 15, 2000 5:15 AM
> To: [email-masked]
> Subject: Unique SSRC IDs?
> 
> 
> Dear RTP experts,
> 
> I'm prepared to be target of a massive flame attack, however I simply
> cannot resist to post this:
> 
> I haven been asking myself the following (maybe naive) question for
> some time: Why are SSRC IDs not reserved in a way that makes
> sure that they are unique for a given session. 
> 
> IMHO the possibility of SSRC ID collisions contributes a lot to the 
> complexity of a complete and correct RTP implementation. At least
> for the RTP implementation I have done recently it would have been
> a significant reduction of error prone code if the SSRC ID would
> be constant and guaranteed to be unique. Essentially the whole 
> problem dealt with in section 8 of the current draft would vanish. 
> I do know that SSRC ID collisions are extremely rare. However, 
> this makes it all the more likely that a given RTP implementation 
> will not correctly handle a collision when it does occur. 
> 
> I am also aware that in order to reserve unique SSRC IDs, some 
> centralized authority to distribute SSRC IDs (possibly
> on a per session basis) is required. While in a multicast
> centered environment this might seem odd (to put it mildly)
> it does not seem to be really inappropriate. The network traffic
> and processing for reserving SSRC IDs should be acceptable even
> for large number of participants, since the required data is
> really small (a couple of bytes, most likely the UDP/IP header would
> account for more data than the content of the packet). In order 
> to protect against the failure of a single server, the SSRC ID number 
> space could be divided to be served by multiple (say a 
> hundred?) servers. 
> 
> What am I missing? Something obvious?
> 
> I would appreciate any feedback ....
> 
> 
> thanks for reading,
> 
> Martin
> -- 
> --------------------------------------------------------------
> -------------
> Martin Mauve                                         
> University of Mannheim
> Praktische Informatik IV                            Phone: 
> +49-621-181-2616
> L 15,16                                             Fax  : 
> +49-621-181-2601
> 68131 Mannheim                         
> [email-masked]
> Germany
> --------------------------------------------------------------
> -------------
> 
>

---

From: Martin Mauve <[email-masked]>
Date: Wed, 15 Mar 2000 17:54:01 +0100

Hi,

thanks for your reply - I would like to comment on your answer:

> of RTP Implementations ???

I'm tempted to answer yes. I was thinking of a unique number service because
I needed to assign unique numbers to objects in a shared virtual world. 
Incidentally I noticed that this would also allow me to get rid of all the
code I had to write for SSRC collisions. Moreover, it might also be useful
for reliable multicast where a collision of the sender IDs might have 
catastrophic impact. To summarize I (maybe naively) thought that something
like a unique numbering service might be something which is interesting for
many applications that need to assign unique IDs in a distributed fashion.
   
While it would be nice to have a global unique numbering service which can
be used for all kinds of applications (including RTP) this is not required
to have unique SSRCs. All that is needed is to make sure that the participants
of a session agree on a (set of) server(s) from which they receive the unique
ID. No need for a new startup company that sells unique IDs, even though
you'd probably be rich within a couple of month if you decided to do so :). 

> that some conversations will happen in non-routable address spaces I do not

This will be an extremely simple database. A set of servers would devoid
the address space so that it is non overlapping (no problem since SSRC IDs
are no scarce resource). To get an ID one would send an identifier for the
session to one of the servers and get back the unique number. The operations
on the server are trivial and the transferred data is minimal. Of course one
could make this more sophisticated with timing out IDs and doing lots of 
other fancy stuff, but the base functionality is so simple that there
should be no real problem. Moreover there might exist an arbitrary amount of
these sets of servers. An number is only unique within one set. So there is
no need to build up a global infrastructure for all applications using unique 
numbers (even though in the long run there might be a lot of applications 
using such a facility).   

> to setup and maintain over the years... Is that cheaper or writting SSRC

Maybe I should rephrase my question:

If there were a unique numbering service which is freely available - would it be
of use, would it be appropriate, for RTP?

thanks,

Martin

---

From: Jon Crowcroft <[email-masked]>
Date: Wed, 15 Mar 2000 17:09:14 +0000

In message <[email-masked]>, Martin Mauve typ

 >>> that some conversations will happen in non-routable address spaces I do not

like multicast address allocation servers one might comment :-)
 
 >>numbers (even though in the long run there might be a lot of applications 

i think that this is also somethign we are wrestling with with object
naming in RMRG and RMT btw....

 >>of use, would it be appropriate, for RTP?

for lots of things

 cheers

   jon

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 15 Mar 2000 14:44:26 -0500

There are several problems with a centralized unique ID allocator:

- yet another point of failure (calls to mind Tanenbaum's dictum about
distributed systems which fail because a system fails that you didn't
even know existed)

- yet another target for a high-payoff denial-of-service attack (neat -
I can shut down the world's telephone, TV and radio by shutting down the
number server...)

- how do you keep me (and various copies of my little virus) from
sucking up all identifiers for some high-profile event?

- firewalls, NATs

- making sure that identifiers get returned - kind of a global DHCP
problem, just much worse

- fast joins for channel surfing add another step (and with channel
surfing, the number of requests to this server could be quite large)

Thus, I'd think that some test code that exercises the SSRC allocation
would be a far more useful contribution. If we ever want to get to
5-nines reliability, we can't keep adding centralized servers whose
failure brings down the whole phone system, radio and TV.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Martin Mauve <[email-masked]>
Date: Thu, 16 Mar 2000 12:20:29 +0100

Hi,

thanks a lot for your comments, they are very helpful. I would like
to apologize for not being very clear in my initial posting. It is not
that I wanted to suggest to develop "unique number distribution" specifically
for RTP. I completely agree with you that from an RTP only perspective
this would be a less useful contribution than test methods for SSRC ID
collisions. After all RTP does work without unique SSRC IDs. However, getting 
unique IDs for distributed applications is a general problem that needs 
a solution. For example, in reliable multicast a collision of sender 
identifiers would likely be not acceptable. In a distributed virtual 
environment the objects typically require unique IDs; here, too, collisions 
are not acceptable.

It therefore seems that the problem of unique ID distribution has to
be solved anyway (addressing the concerns you mentioned). I was merely
curious if, given the existence of an appropriate solution to the 
distribution of unique IDs, it would be of use for RTP. It seems that,
at least for RTP, it would cause more problems than it would solve, mainly
because RTP can deal with non unique IDs (even if this causes some 
complexity in the protocol).

Nevertheless I'm quite convinced that a unique number service is an 
important thing. Even though I find the problems you describe very 
challenging and I'm not certain if all of them can be solved adequately,
it seems certainly worth trying. I'll probably be back in a while to 
haunt you again :).

Thanks for the constructive and flameless critique,

Martin

-- problems exist to be solved -- 

-- 
---------------------------------------------------------------------------
Martin Mauve                                         University of Mannheim
Praktische Informatik IV                            Phone: +49-621-181-2616
L 15,16                                             Fax  : +49-621-181-2601
68131 Mannheim                         [email-masked]
Germany
---------------------------------------------------------------------------

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 16 Mar 2000 10:51:03 -0500

Martin Mauve wrote:
> be solved anyway (addressing the concerns you mentioned). 

I'm not so sure. Its possible (and is often done), to generate unique
IDs without a central server to guarantee that uniqueness. The problem
is that these IDs are long. Its not an issue for many protocols that use
them, but RTP is different since its packets are so short. Having a 20
byte UUID in the header for a G.723.1 voice packet is simply too much
overhead. Thats why RTP uses this SSRC, which is short, and then binds
it to a unique ID (note that this ID is chosen locally and is still
unique), the CNAME, sent in an RTCP packet.

So, a global unique ID distribution service is only needed for protocols
where the cost of transferring a 20 or so byte identifier is too high. I
somehow doubt this is a very large set of protocols.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: "Hungkei (Keith) Chow" <[email-masked]>
Date: Thu, 16 Mar 2000 12:08:51 -0500

Another alternative would be a SSRC-swapping, just in the same way as
label-swapping (MPLS).
But certainly you need to maintain a mapping table locally and do signalling
before sending.
-- Keith.

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 16 Mar 2000 17:22:49 +0000

In message <[email-masked]>, "Hungkei (Keith) Chow" t

 >>But certainly you need to maintain a mapping table locally and do signalling

 Keith,

but the state for this is centralised - i.e. if the ssrc-swapper
crashes, you are back to the same prob. as a single unique id
server....or you have to replicate and syncronise such servers .....and
that starts to sound like yet another IN hack in the internet:-)

i think there's two most promising attacks
1/ jonathans
2/ a general unique id service, which could be useful for lots of
things including this, but is a longer term proposition...(well worth
pursuing imho, but not obviously as an ietf wg item yet...)

 cheers

   jon