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.""
Put someone elses screen name (i.e. "admin") in the dropdown list for AOL by default. 99% of users won't be able to figure out how to change it so they can use their own screen name. And the ones that do, are smart enough not to download thousands of MP3's via a 56k AOL connection :)
I am !amused.
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?
By Carolyn Duffy Marsan
Network World, 01/14/02
The Internet engineering community has run into a significant technical hurdle in the development of an industry standard to support instant messages with multimedia attachments, such as audio or video clips.
If leading instant messaging service providers such as AOL and Microsoft offer multimedia instant messaging services to their millions of users, Internet communications could ground to a halt. Service providers now support only text-based instant messages.
The Internet Engineering Task Force (IETF), which identified the multimedia instant messaging problem, is soliciting potential fixes from its participants and plans to debate these fixes at its meeting in March.
IETF leaders say protocols being developed to support text-based instant messaging won't handle multimedia instant messaging attachments. They say a new communications protocol is needed to transport those files. This new protocol must provide congestion-control mechanisms to prevent instant messaging users from overwhelming the Internet's backbone with MP3 music files, photos or voice clips.
"There would be a potential for an AOL usage [of multimedia instant messaging] to either swamp out the rest of the Internet or to require major engineering to stop what we call a congestion collapse, where you cannot send new traffic into the network," says Allison Mankin, co-chair of the IETF's transport area. "This is a big enough problem to need urgent attention."
Demand for multimedia instant messaging is expected to be strong. Text-based instant messaging is popular on the Internet and private, corporate intranets. With multimedia instant messaging, users could send attachments along with chat sessions.
"Our researchers would love to have voice chat integrated with instant messaging, mainly to kill the international long-distance calls," says Ross McKenzie, director of IS at Johns Hopkins University. "Our dean has a research center in Nepal. I know that if I offered that service, he'd be on it tomorrow."
Johns Hopkins began offering regular instant messaging services to 4,000 faculty and staff members in August. Today, instant messaging is the most popular application on the university's Web portal, with more than 1,500 users racking up 60,000 minutes of instant messaging messages per month.
"If we offered [instant messaging] attachments, our faculty would be exchanging chapters out of books. But what they'd really like is voice," McKenzie says. "Our researchers want ad hoc, integrated voice and chat. They want it in Katmandu, at home, at Starbucks or wherever."
Today's instant messaging services use what's called a paging mode, where the signaling information that initiates the chat session is carried along with the text of the chat session using a single protocol.
After four years of effort, the IETF is finalizing a protocol dubbed SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions) that will let the paging mode work across different instant messaging service providers' offerings. Once deployed, SIMPLE will let AOL users exchange text-based instant messages with users of rival instant messaging services from Microsoft, Yahoo and others. Both AOL and Microsoft have vowed to support SIMPLE.
SIMPLE uses Session Initiation Protocol (SIP) to initiate an instant message and to transport it on a hop-by-hop basis across the Internet. While SIMPLE can handle short, text-based messages of up to 1,000 characters, IETF participants have discovered that it cannot carry attachments to instant messaging sessions. This is because of an inherent problem in SIP, which runs on TCP or User Datagram Protocol (UDP). While TCP features built-in congestion controls, UDP does not.
So UDP should not be used for sending large files. And SIP can't be adjusted to eliminate the possibility that large files would be sent over UDP. That scenario would be catastrophic, Mankin says. "Imagine the after-school surge, with millions of teenagers online and sending MP3s to each other," she says. "We're talking about volumes of traffic that may be half of the backbone."
Mankin says even if AOL were to offer multimedia instant messaging attachments only to its own users, that could still cause congestion problems across the Internet if this issue isn't resolved.
"We can't tell AOL what to do, but they use all the major backbone providers," she says. "If UDP could be used by their [multimedia instant messaging] service, that would be a serious problem."
The IETF is working on a solution that will use SIMPLE to initiate multimedia instant messaging sessions but will rely on a different protocol with built-in congestion control to transport attachments. So far, the IETF has identified several options for that transport protocol, which will use what's called a session mode rather than a paging mode.
The co-chairs of the IETF's SIMPLE working group are asking participants to submit additional proposals for the session-mode transport protocol this month. The group hopes to select one of the proposals by June.
Jon Peterson, co-chair of the SIMPLE working group and a senior technical industry liaison with NeuStar, says the new transport protocol will scale better to carry large volumes of instant messages and multimedia attachments.
"If the No. 1 and No. 2 [instant messaging] providers were going to interconnect, this would be really useful to handle the high volumes of messages," he says.
Meanwhile, government regulators could prevent AOL - the largest instant messaging service provider - from offering multimedia instant messaging services until this technical glitch is resolved. To get approval for its merger with Time Warner, AOL agreed to delay the release of multimedia instant messaging services until it opens its instant messaging system to rival services.
AOL failed to return multiple calls seeking clarification of its multimedia instant messaging plans. But AOL vowed last summer to use SIMPLE to provide interoperability with other instant messaging service providers.
The rest of the instant messaging industry is expected to adopt SIMPLE too, with Microsoft already shipping SIP support in the latest release of its MSN Messenger software.
In related news, the SIMPLE working group. plans to submit documents that detail how the paging mode works to the IETF leadership for approval in the next few weeks. A draft standard could be approved by March.
The multimedia instant messaging hurdle "is not a show stopper" for SIMPLE, says Robert Sparks, co-chair of the IETF's SIMPLE working group and a senior software architect with Dynamicsoft. "It's new functionality that a lot of people really, really want. But the [SIMPLE] method is sufficient to replicate the [instant messaging] services we have right now."
--
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.
My question is, since AOL uses unique screen names instead of ID numbers, how will they handle screen name overlaps between the instant messenger databases?
Nicotine free Amish .sig.
The article seems to make some claim that mp3's, video clips, photos, etc are different from file attachments. I've been able to attach files to ICQ for years, but you have to send direct. Maybe they mean the ability to send through ICQ's server. Or maybe AOL is going to add an "attach mp3" to replace "attach file" in the ICQ client and the usage will go way up.
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.
Along that route, why clog up everyone's email servers with MP3's, when you can just upload it to a FTP server you and your friend have common access to?
Besides, lots of email systems are already set up to filter out large attachments.
After all, when transferring files, it only seems logical to use the File Transfer Protocol.
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...
The overhead for switching from IP to some other protocol is expensive (don't bother pointing out IP being wrapped in another protocol like ATM because I don't see ATM equipment being cheap or easy on the processing power). Besides which the headend links where IP is converted to some other addressing scheme are still going to be swamped with traffic flowing in and out of them. The problem isn't IP the problem is not enough bandwidth on the local end to meet the demand generated at the local end.
I'm a loner Dottie, a Rebel.
- Online chat in it's various forms is popular.
- Folks are starting to use chat clients to send files to eachother.
- Chat is moving from text to audio or audio/video.
All of these features have been around for quite awhile, integrated and not. However they're now getting rolled into all-in-one applications that are popular. Also a critical number of folks have fast connections and are now comfortable going to the computer to send/recieve/interact.Big news? No. Entirely forseeable evolution is more like it.
Things like IRC already enables a lot a lot of these features, and so do the various video-whackoff online applications and big-scale internet telephony has been the promised for a few years now. But those are all small potatos compared to the market penetration of AOL IM / ICQ / MS Communicator / Yahoo Messenger. With these now offering these feature traffic is going up, up in a big way.
No need to download a specialized program, install it, and figure out which of your friends has the same or compatible ones. The big IM programs are pretty much ubiquitious in the mass market, heck they come pre-installed on many new computers. Co-workers, classmates, relatives, friends across the street or in distant parts of the world are going to be likely to have the software, all installed automagically as they upgrade their tried-'n-true chat programs.
So we're now back to the issue of cross-communication: How to get the AOLians to talk to the MSNers with the ICQites with the Yahoolies. A solution has been promised for text messages but now after all these years it's arriving just in time to be irrelevant, perhaps simply being the building block for a more versitile system.
So what are the big technical hurdles? Again, three:
- Directory Services: How to find and connect to folks.
- Interoperability: How to negotiate settings & protocols between various clients.
- Traffic Management: What to do with all of these packets streaming from the previously almost-all downloading users who now want to send streams of highspeed data upstream, LOTS of it (think teenagers on the phone!.)
So why is this an issue for NetworkWorld and not Teenbeat? Because directory services means some sort of servers, interoperability means protocols and that surging volume of low-latency traffic going upstream is going to upset the pricing and service model most broadband is built on.Again, none of this is new, it's just the matter of scale. Currently in most environments the 5% of folks who are considered "Top Talkers" account for over 50% of all traffic. What happens when half of the users become "Top Talkers"?
If you're selling webcams and mikes and soundcards and sticky applications that folks spend hours on and want lots of services from then it's all golden. However if you're an exec in the already shaky ISP market this is like seeing the first few seconds of an avalanche and knowing those that the avalanch has effectively started...
I don't read ACs: If a post isn't worth so much as a nom de plume to its author then I wont bother either.
The real issue is the possibility that your client will use UDP. UDP is normally fine, but it doesn't handle reliable delivery, and people using it who want reliability won't necessarily do so correctly (i.e., by using TCP, not UDP).
UDP is intended for things like realtime audio. If a packet gets dropped, the receiver doesn't want that packet anyway. (I.e., If packet 3 gets dropped, the receiver will play packets 1, 2, nothing, 4, 5). For file transfer, you want every packet, so that you get the whole thing eventually. If you use UDP (and, in particular, if everyone uses UDP), you'll get a lot of resends in a non-optimal pattern.
So the problem isn't in sending files as packets, it's in sending the packets in an inefficient way. Essentially, they're worried that it will be done like NFS instead of like FTP.
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..
Comment removed based on user account deletion
Just disconnect AOL from the rest of the internet. We won't miss them, and I doubt 1 in 100, stellar AOL customers would even notice the difference.
errr....umm...*whooosh* *whoosh* Is this thing on ?