Slashdot Mirror
IETF Mulls Standard For Multimedia Messaging
ennuiner writes: "NetworkWorld is running a story this week about the IETF's efforts to help create a universal standard for multimedia messaging. According to the article, a new protocol is needed because the volume of mp3 traffic on AOL could reach the point "to either swamp out the rest of the Internet or to require major engineering.""
How about an advanced cache system, a master cache or multimedia files as they get sent, files matching the same name/size/crc value get sent down to smaller cache hubs. Larger isps could host these cache hubs, the incentive for them would be less bandwidth external to the network.
Everyone downloads this King fu flash video...
User A goes to download it, and he is the first ISP-X user to download it, it now resides in ISP-X's multimedia cache. When User B goes to grab it, he is redirected to the cached.
similar to a DNS system, where changes filter down.
Now for the privacy concern, could this be limited to multimedia, how secure would these caches be? Can someone browse them?
What exactly possesses these kiddies to believe that their little friend Suzie needs this MP3 right now as opposed to a minute or three from now? Why the hell can't they just send Suzie an email with an attachment? Call me old-fashioned, but this strikes me as a problem that would just go away if AOL took the "attach big old binary stuff" button off of their IM client.
Cantankerous old coot since 1957.
They want a new protocol that will specifically include congestion control.
So they are going to try and market products with "we know it doesn't transfer mp3s as fast as our competitors but it's more community friendly"
Whilst congestion friendly protocols - like how real drops packets if you cant stream fast enough - are great for some purposes they just aren't going to cut it here.
Who's going to use an instant messenger product that sacrafices performance for the greater good.
Napster was the killer app for broadband users, it's just a shame that it also killed broadband networks - not that the users cared.
First of all, AIM, and I would imagine other instant messengers already support the transfer of video or audio clips, not to mention images or damn near anything else you'd want to send. Its called FILE TRANSFER people. It happens all the time. Its rather naive to say that they only support text. Someone isn't doing their research.
Worried about overwhealming the backbone with mp3s?? How exactly is this going to happen? Napster at the height of its craze caused some college campus network admins to wring their hands a bit, but the internet backbone didn't seem to have any serious problems as a result.
The article sounds like the technologies they're discussing are things that will hit in the future, when they've already been pretty prominant for the last few years.
Want to integrate voice chat? Don't netmeeting and other similar programs provide this capability already? Yet for some reason, the backbone is still intact.
The way the authors of that article sound, they seem to imply that everyone has broadband service and the backbone is this one single connection that will "run out" if we don't cut back on all this multimedia trading!!!!
If the transfer rates increase, then the upstream providers will increase to compensate. The backbone won't crash as a result of this. They will expand as needed. And if the kids start trading mp3's in such enormous volume that it would grind the backbone to a halt, the individual
ISP's who rely on overbooking their bandwidth to keep costs low will have no choice but to raise the rates to their more bandwidth heavy customers.. thereby solving the problem.
Don't worry people. Its not the end of the world.
-Restil
Play with my webcams and lights here
I still prefer pine for email, trn for usenet, gnut for gnutella, and ncftp for ftp. I get annoyed when people email me attachements -- I'd prefer a URL.
The thought of everyone and their dog wisking voice and video at me kinda bugs me. Whatever happened to the "talk" command?
I'm only 29 and I'm starting to feel like that "condescending unix computer user" in Dilbert. :)
Method of processing duck feet
If you read the article they mention that any voice and video or other data transfer mechansim integrated into instant messaging *must* support congestion control. Funny they mention that because TCP has congestion control, and works just fine (TCP traffic will not collapse the net)
/dcc for IM clients)
Later on you read about various existing technologies that use UDP, and this is what the IETF is concerned about. Traditionally voice and real time video require low latency transmission where order and reliability is not as critical as latency. These applications use UDP specifically for this purpose, and this is why the IETF is concerned.
They are deathly afraid that AOL or MSN or some other giant will release a chat client that supports voice or video using a UDP transport, without congestion control, and that all these millions of users spewing UDP packets into the net will cause a congestion meltdown.
The probability of this happening is about zero. Any network programmer worth half a grain of salt would know about the problems inherent in using UDP, and for general MP3 file sharing, etc, they would integrate a TCP based transport (AIMster already does this, as do many others. Think
So this article is really much ado about nothing. No one is going to use UDP to transfer mp3's, and no one is going to integrate reltime voice/video into an IM application without working out the congestion control details.
I think this is more of a publicity stunt than anything else...
Yes, email is definitely not the way to do this, you're 100% correct about that, except you have to provide a couple of things for your alternative to work: an FTP server. And an ftp server with rights assigned to individual users who are not admin on that system. So whoever is admin of the system and owns the box is subject to the wrath of the RIAA/ MPAA along with the users. Well that's not going to attract a lot of ISPs in to providing this facility for their customers.
DCC makes more sense. Consumers of ISPs have pretty much been all told not to run publicly accessible FTP servers, and ISPs setting up this service for monthly subscribers to upload the MP3 directories is not going to happen so what's left is peer to peer client-client connections a la IRC mp3 channels. This is pretty much how tranfers between AIM chat clients work now I bet.
The relevant issue is more proabably: how to accelerate transfer by cacheing - without becoming legally liable.
files as they get sent, files matching the same name/size/crc value
get sent down to smaller cache hubs. Larger isps could host these
cache hubs, the incentive for them would be less bandwidth external to
the network.
>Congratulations, you've just invented USENET!
The original poster, wo1verin3, also mentioned a need for privacy, so
for the complete solution, he would probably have to invent
Freenet.
Let me elaborate. There are basically two kinds of content that
people might want to throw around the net using IM's. The first is
original content from that user, like voice phone data or the MPEG of
the family get-together. (Or for the pr0n industry, people who are
acting in a way that might cause a family, getting together.) The
second kind of content is copied content that likely has a wider
audience than just the people on one person's IM buddy list.
For pretty much everyone, the amount of original content that they
create is an order of magnitude less than the amount of content that
they are interested in viewing. However, to accomodate the
person-to-person phone calls and such, whatever weird schemes the IETF
puts together regarding avoiding UDP packets and what not will be
required. But such content will not be the major part of the traffic
load, and if you read the article carefully, it's not the part of the
traffic load that any of the people actually from the IETF are quoted
in the article as worrying about.
The real problem is content that is intended for a general audience,
but efficient distribution of such information in an anonymous manner
is readily available by simply sending references into Freenet rather
than the actual content data itself. The sending IM peer can verify
that the data is available in Freenet, upload it if necessary, and
then send the Freenet ID text to the receiving IM peer, which can
download the data through a path that has been minimized to the extent
that people "close" to the receiver have previously downloaded that
data. (cf. freenetproject.org)
Now, I'm not exactly on the IETF suggestion-in-box-list, but to me
it's strange that all of these bright people, many likely employess of
AOL-TimeWarner and other large computer and media firms, haven't
figured that Freenet or Freenet-style distribution is a simple
solution to the problem... Of course, I'm being sarcastic, as we
shouldn't be surprised if organizations with the obvious corrolorated
political agendas are reluctant to note that extensive promotion,
product integration, and use of Freenet will help to resolve this
difficulty.
Three Rings for the Elven-kings under the sky,
Seven for the Dwarf-lords in their halls of stone,
Fifty for the contest winners on their couches with remotes...
I will never understand the IETF, I must say. They cannot even agree on a standard for Instant Messaging, NEVER MIND Multimedia messaging..
How is ANY standard they are going to put forth going to be worth a DIME if they cannot even agree on a solution for basic TEXT messaging?
-- I'm the root of all that's evil, but you can call me cookie..
- require expensive high-capacity FTP file servers with giant pipes to the backbone, run either as a public service or as part of a specific ISP offering
- expose said giant servers' operators to (RI|MP)AA-led prosecution and lawsuits given all the ripped media that would be stored there
- cause the transferred files to take nonoptimal routes between the sharing users. IP is already designed to find a best path; what's the sense in forcing a detour?
So, yes, by all means, use FTP. But do it by putting ftpd on each user's machine, most likely wrapped inside the IM client. And rather than 'attaching' the file to the message itself, tweak the UI so that sending the file looks like attaching, but really triggers an ftp upload. It's not like it's going to get there any faster as a message attachment. The client can asynchronously alert the receiver when the upload is complete.What's the problem with this design? What requirement am I missing?
When all you have is a hammer, everything looks like a skull.
Comment removed based on user account deletion