Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
The Internet

IETF Mulls Standard For Multimedia Messaging 145

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.""
This discussion has been archived. No new comments can be posted.

IETF Mulls Standard For Multimedia Messaging

Comments Filter:
  • by Anonymous Coward
    Text.
  • by 11thangel ( 103409 ) on Monday January 14, 2002 @06:38PM (#2838721) Homepage
    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 :)
  • by wo1verin3 ( 473094 ) on Monday January 14, 2002 @06:41PM (#2838747) Homepage
    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?
    • How about an advanced cache system
      Two problems: first, they're talking about messaging, not downloads from a central source, so it's harder to match the message attachments to a central cache image. Second, one of the major applications they're talking about is verbal chat, where there isn't a single high-demand image, but rather a separate recording attached to each message.

      That said, I'm sure a good chunk of the multimedia traffic would, in fact, be people passing around the latest hot recording.

      • by Anonymous Coward
        actually the article general refers to reducing bandwidth for multimedia files including but not limited to mp3s as well as voice chat / text.
      • Well, if everyone stopped wasting bandwidth with inefficient email systems, even more inefficient unproxied and unshared web connections, and stunningly inefficient common file transfers, there may be enough spare bandwidth to allow the kind of transfers that require unique point-to-point communication, such as voice over IP and unique file transfer.

        Fix the 'x' million identical HTTP transglobal connections every hour for the Hotmail homepage for one.

        Distributed on-demand cacheing would be my first step. Scrapping a pull-based transport mechanism like HTTP would be the next. Freenet is a nice first step.
    • Exactly how many terabytes will this server have? That's one hell of a cache.
    • by Tackhead ( 54550 ) on Monday January 14, 2002 @06:52PM (#2838807)
      > 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.

      Congratulations, you've just invented USENET!

      • It seems to me that USENET servers don't usually cache content on demand. If, for instance, you want to read a newsgroup your server doesn't currently carry, it doesn't just fetch it quickly. In my experience, at least ;-).

        Completely different system.
      • More Precisely... (Score:2, Insightful)

        by Nopaca ( 98621 )
        >> 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.


        >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...

      • +87 funny
    • by Anonymous Coward
      Hrm...

      Legal implications for caching a copyrighted material? I try to download the new Backside boys track and I pull it from my ISP instead of a user on music city...is the ISP liable for spreading that work?
  • by The Gardener ( 519078 ) on Monday January 14, 2002 @06:42PM (#2838756) Homepage

    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 [ietf.org] (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."

    • Netmeeting uses standard protocols, and is easy enough to use, and integrated into Messenger (MSN Messenger was origionally developed by the Netmeeting team at MS)...

      it's already there
  • It's called MIME (Score:4, Insightful)

    by HisMother ( 413313 ) on Monday January 14, 2002 @06:43PM (#2838758)
    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.
    • It's called FTP (Score:5, Interesting)

      by Stiletto ( 12066 ) on Monday January 14, 2002 @06:53PM (#2838812)

      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.
      • Re:It's called FTP (Score:1, Interesting)

        by Anonymous Coward
        FTP is a nightmare in general, and using FTP for instant messaging clients is no exception....shudder.
      • by marick ( 144920 )
        And while you're at it, why not just put it up on a good old WebDAV server that you both have access to, and it will appear magically (via Web Folders) in Windows Explorer (or the DAV file system on Linux or Mac OSX).

        It's hard to imagine anything easier and more transparent than that.
      • by Anonymous Coward
        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.
      • Re:It's called FTP (Score:2, Interesting)

        by BlowCat ( 216402 )
        Just a few questions.

        1. Who will purge the stuff once it's unused?
        2. Will the server admin be liable for illegal content?
        3. How will authentication be handled?

        By the way, do you know that FTP sends plain text password over the net?

      • Re:It's called FTP (Score:4, Insightful)

        by isomeme ( 177414 ) <cdberry@gmail.com> on Monday January 14, 2002 @07:57PM (#2839082) Homepage Journal
        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?
        Most /.ers have access to FTP servers that they could use in this way. But most AOLers don't. So doing this for the full community would
        • 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?

        • FTP uses TCP. The end-to-end signalling and short message sending may have been established using SIP (which uses UDP by default) which possesses some means to get through NATs and Firewalls. Now for FTP you need to do the jumping through hoops again ...
      • That would be why I actually only use FTP for transfers anymore ;P
      • The "desktop" idea has already been yelled and screamed at as a bad idea. And simply, a FTP server is going to be way too hard to use.

        OK, I have it easy. I mount my web site as a folder on my local machine, and to "upload" a file I just "Save as ..." in the GIMP and POW! It's published on my web site within seconds. But even that is a little bit difficult

        So if you think people, AOL users even, are going to be using FTP ... na, forget it.

        FTP daemons are as buggy as hell. Read Bugtraq - all the FTP daemons you can write to have exploits, and the only secure one I know [cr.yp.to] has no upload facility.

        Windows XP has the right idea with clicking "publish to the web" or whatever nonsense they've built into the folders. But it is still too difficult.

    • It's called Ease of Use. This is a revolutionary new development in User-Friendly, Hassle-Free Internet-Wide DOS Attack Utilities.

      Give a man a fish and he eats for one day. Teach him how to fish, and though he'll eat for a lifetime, he'll call you a miser for not giving him your fish.
    • Hang on, why shouldn't everyone be able to send files when they want?

      I saw some argument going up about emails being delivered straight away in some cases, but sometimes taking days. Someone pointed out that 10 years ago you would never have got the speed of delivery you get now. Everyone promptly pointed out we're in the 21st century, the 'Internet Revolution' and we should have the ability to do reasonably simple things like this. Same applies here.

      Yes, people should be able to send files, and yes, internet traffic *is going to increase* over the next few years. Pepole will want, and demand more, especially with broadband links going up left right and center. The backbone MUST be able to support this.

      Yes it costs, and maybe the increased costs that I'm sure will be passed on to the customers may slow down things for a bit, but most people can see that the future is going to be a much faster, repsonsive and more importantly, *useful*, Internet for all of us. It's just a case of when.

      Oh and one more thing, I believe hotmail is limited to 1 or 2mb per account. Most teenagers use hotmail. That's why they don't email mp3s (or one of the reasons).
    • Sending attachments via Email will ensure that AOL sucks up another 33% of internet capacity. The current [default] binary encoding scheme of BASE64 has a 33% overhead. I'd rather see people send URL's in their emails. (Hey! a new XP feature, send an email, and allow people to come right in and pick it up from your PC...oh wait, they've already got that)
  • Get rid of AOL and it will force people to learn how to use the computer. It will help get rid of spam since a lot of it seems to be directed to AOLers who dont know what it is. I say no more aol. Set everyone up with a nice linux box connected to MyLinuxISP [mylinuxisp.com].
  • Screen names? (Score:3, Interesting)

    by Datafage ( 75835 ) on Monday January 14, 2002 @06:43PM (#2838766) Homepage
    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?
    • The last proposal I remember reading (admitedly, this was Spring '00 when the IMPP group list degenerated into flamewars and I stopped following it) was simply to tag things with username@service or impp://service/username. There's several solutions, I'm not sure which one they're going with but it shouldn't be a big issue.
    • The companies will support the same transfer standard, this is different then merging the two databases.

      The AIM / MSN systems will not communicate with each other, they will just use the same file transfer method if this works out.
    • Same way jabber does, by indicating the server / service of the other person as a part of that person's ID (eg: foo@jabber.foo.com )

      So if there's a "kradkkool" on aim, and a "kradkkool" on msn, they'd appear externally as "kradkkool@aim" and "kradkkool@msn", respectively.
  • Well, there is one better solution. A mob of people carry pitchforks and shovels could march on AOL's headquarters and pull the plug.

    Then I guess all those high-paid type people that sit on standards comittees would have to find something else just as worthless to fill the big gap in their schedule.

  • From the article:

    "Both AOL and Microsoft have vowed to support SIMPLE."

    Wouldn't that be a surprise?

    Enough with the sarcasm. Am I wrong in the understanding that when I instant message (IM) with someone, that our IM clients have knowledge of each other's IP addresses once they are resolved for the first time? What's so bad about sending files broken out as packets to another IP address?
    • What is so bad?

      The article talks about the sheer amount, or volume of data being transferred.

      You aren't just taking up bandwidth on your system, and the recievers system by sending a file. Your information must be routed and uses resources from many other computers to reach it's destination.

      On the net, the quickest path between a and b is not a straight line.
    • Am I wrong in the understanding that when I instant message (IM) with someone, that our IM clients have knowledge of each other's IP addresses once they are resolved for the first time? What's so bad about sending files broken out as packets to another IP address?


      Well, a huge proportion of users would be behind a firewall or NAT or something, and wouldn't be able to have a port open for incoming connections. If that applies to both sender and receiver, neither of them are able to accept a direct connection from the other party. Then the connection from A to B would have to go through some IM-server middleman, and the packets would most probably go on a less than optimum path.

      NAT users have an inferior internet connection. And yet, to try to please all these people, protocols do a lot of costly and unneccessary workarounds.
    • by iabervon ( 1971 ) on Monday January 14, 2002 @07:37PM (#2838999) Homepage Journal
      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.
  • Why would having voice chat be a big problem? Shouldn't we be worried that Cisco and everyone else is rolling out IP phones?
  • article... (Score:4, Interesting)

    by SETY ( 46845 ) on Monday January 14, 2002 @06:48PM (#2838792)
    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.
    • Ever tried it while behind a firewall?
      • Yeah actually I use to do that. That's a pretty valid point since alot of people are behind firewalls. ICQ protocol could certainly be redesigned to be more firewall friendly. Like using 1 port instead of a like 20 (in the 2000 range, if I remember correctly).
  • by grahamsz ( 150076 ) on Monday January 14, 2002 @06:51PM (#2838804) Homepage Journal
    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.
    • last one left standing of course .. you think router admins are going to handle traffic for somone not willing to obey the simple rules of the road?
    • Their competitors don't transfer mp3s yet. If something that includes congestion control lands first, AOL might pick it up, and not have multimedia IM without congestion control. Since I don't think AOL does point-to-point messages, they'd probably be really happy to have the congestion control, too.

      Furthermore, the people who will probably most like congestion control are the end users. Most people have a really slow connection at the lasthop, and all of their traffic has to go through that link. So if they're running multimedia IM full-blast, any time someone sends them an MP3, their web surfing will slow to a crawl.
      • Actually, when you try to send an image in AOL, you directly IP-to-IP connect to them, completely bypassing the AOL server, allowing you to send any file (not just images) to them. AOL doesn't route any of the files themselves. I don't know why this seems so novel - AOL's had it for about a year.

        (By AOL I'm talking about AIM, I'm proud to have no experience with the AOL client)
    • It is better to get through slower than not at all. *I* might think that I can get through faster by not implementing some form of congestion control, but if the strategies I use cause other trafic to be unfairly penalised, someone is going to come up with ways to penalise my traffic. This sort of thing has come up in the past with queuing in routers.

      It can be a bit like traffic flow in a city...not entering an intersection when my exit is not clear might slow me down a little, but if I block the intersection and cause gridlock it will cause a lot more. So if there happens to be a policeman observing, hw might penalise me if I do the impolite thing.

      IP solution to traffic congestion...car crushers at all major intersections!

  • WHAT?!?! (Score:5, Insightful)

    by Restil ( 31903 ) on Monday January 14, 2002 @06:54PM (#2838818) Homepage
    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
    • Re:WHAT?!?! (Score:3, Informative)

      The reason the author's of the article are worried is that SIMPLE, the new instant messaging interconnect protocol, supports UDP as well as TCP. UDP has no congestion control. It is horrible to transfer large files with as most applications end up resending too many packets. This could, in fact, bring backbone segments down.

      Of course "Its not the end of the world" The end of the article even said that it wasn't a "showstopper" for SIMPLE. But it is a genuine problem.
      • Re:WHAT?!?! (Score:3, Insightful)

        by curunir ( 98273 )
        However, the article intro that people see above doesn't exactly make it sound like it is a problem with SIMPLE. I think we've been a victim of article marketing. If the /. intro read, "We came up with a cool new protocol, cept now we realized its kinda broken for file transfers" would you click through to read it? But if it says, "Internet could grind to a halt because of AOL users insatiable need to chat and their inability to be happy with plain text IM'ing" more people will read it.
      • SIP (rfc2543) provides the means to negotiate how the multimedia data is exchanged -- typically using embedded SDP (session description protocol rfc2843 ... I think) . If the IMs were to agree to an extension of SDP to include FTP locations ... then the file transfer congestion controls would kick. SIMPLE does not have a problem. SIP messages, the signalling protocol, can go on UDP while the media it is controlling can go on other transports/protocols.

        The title is too frightening for a relatively simple article.
    • Re:WHAT?!?! (Score:2, Insightful)

      Thanks for making sense.

      Bandwidth is NOT a fossil fuel that can be used once and then it's gone. It's created when people build and install computers and pipes according to a logical plan. Of course, that's oversimplifying it - bandwidth is actually created by the application of lots of money and cooperation - at one time, the government's money and universities' money - now increasingly corporate money. Bulk bandwidth where I come from (.au) is almost completely owned by telcos.

      Growing multimedia demand isn't causing bandwidth problems - the lack of purposeful infrastructure scaling (supply) to suit the Net's current capabilities and societal requirements (demand) are manipulated for profit first and foremost.

      Artificial scarcity is the oldest trick in the (economic) book - I'm sure you're familiar with the De Beers diamond story.

      We don't need workarounds to solve these problems. Short of outright economic reform, we need widespread connection sharing, the empowerment of local-level ISPs to network and form their own infrastructure and peer-to-peer to become the norm, especially for heavy things like LOTR trailers, Counter-Strike releases and such.

      • Bandwidth is NOT a fossil fuel that can be used once and then it's gone.

        It's kinda similar. Bandwidth exists at only a nanosecond in time in which it can be used, and then it is gone. If your T1 sits idle for 12 hours, you can't use that bandwidth when it is maxed out 2 days later - unless you have a company with creative billing :)
  • The article isn't about MP3's, those already casue problems. The article is about instant messaging using voice chat or video chat.

    Can't anyone read anymore?

    • Can't anyone read anymore?

      What? You mean, actually read the article? Come on, this is Slashdot!

      Give a man a fish and he eats for one day. Teach him how to fish, and though he'll eat for a lifetime, he'll call you a miser for not giving him your fish.
  • by Deagol ( 323173 ) on Monday January 14, 2002 @07:00PM (#2838842) Homepage
    Is IM really that great a thing? I've never had the desire/need to try it out.

    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. :)

    • yes... you ARE old school.. hehe ... I didnt think anyone remembered the TALK command.. but BTW that IS instant messaging...
      • Is current IM real-time? I got the impression that users received a complete message in one pop -- kinda like MUDs, etc. With talk, it was more like a phone conversation, where both could talk at the same time.

        Man, I'm feeling old.

    • Hell, I'm 18 and I feel like that condescending unix computer user! Not to the extent you seem to, I use ICQ as alot of my friends do, but I think that has alot to do with the age of my friends and the 'net that they were first introduced to. Thing is, while all of them were oggling Napster, I looked at it, and asked "this is better than irc how?" I guess it really depends on how you want to use the net, and what you're willing to learn to do it. I'm so much happier after having switched to pine from Netscape Messenger for my email. When I did that, I actually felt like I was making progress!

      As for: Whatever happened to the "talk" command?

      Talk is where I turn when ICQ fails. And LICQ has been having it issues lately, with large UINs and what not, so talk has come in very handy indeed.

      • [OT] Napster vs IRC (Score:1, Interesting)

        by Anonymous Coward
        while all of them were oggling Napster, I looked at it, and asked "this is better than irc how?"

        Maybe you were born knowing everything about IRC, but the rest of us had to learn it, and it was a pain at times.

        With Napster, you load an app, type in the name of the song you want to hear, and download away! You don't have to invest time in finding a pirate mp3 channel and learning how to deal with all the different variants of file-serving bots. You don't have to suck up to 14 year old w4r3z d00dz to get what you want. You don't have to deal with the playground politics of the IRCops and the script-kiddie users.

        Face it, using the big IRC networks has become like trying to hold a conversation in the middle of a grade school king-of-the-hill match. Trading mp3s is like trying to conduct a drug deal in the middle of the same melee. It can be done, but it's a pain, and napster offered an easier way.
  • by PureFiction ( 10256 ) on Monday January 14, 2002 @07:00PM (#2838845)
    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)

    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 /dcc for IM clients)

    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 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 /dcc for IM clients)

      Ah, but you assume AOL or Microsoft has a network programmer worth half a grain of salt.

      ;-)

    • by Anonymous Coward
      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 /dcc for IM clients)


      You would probably be amused by the SIP specification, then [ietf.org], which is what SIMPLE is based on.
    • > 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

      I think their fears are legitimate. Consider that a decent network
      programmer will demand a much higher salary than a crack monkey with a
      copy of Network Programming for Dummies. Right now, there's probably
      a startup out there that does UDB-based IM with a really
      pretty
      client written by that crack monkey. All it takes is for
      one of the big boys to buy them and incorporate it into their service,
      and you know the suits aren't going to care what the service does to
      the competitor's part of the Internet.

      This is exactly the same sort of thinking that brought us pollution and spam.
    • Any network programmer worth half a grain of salt would know about the problems inherent in using UDP

      Perhaps more importantly, within days - or quite likely hours - of any such braindead application being deployed, any network engineer worth half a grain of salt will figure out to deal with it. Ports (either logical UDP port numbers or physical phone-line ports) will be throttled or blocked PDQ. Ingress points will deny UDP entirely if they have to. As others have pointed out, there are plenty of network programmers not worth half a grain of salt, but a few strategically placed people with half a clue apiece can prevent the former group from doing any serious damage.

  • Doesn't IPv6 take care of all of this, it is the "Next Gen protocol". Why doesn't AOL impliment it?
  • Gotta woman over in Columbus., OH.

    Wanna go downtown...
    To see my gal....
    Wanna sing her a song...
    and show her my ....
  • Currently we have MBone a high bandwith network built for multicasting. In my opinion it would make sense for instant messenger service providers to work with ISP's to create a similar network dedicated to isntant messaging. It needent even run a form of IP, instead it could run some kind of protocol 100% designed for instant messaging
    • Re:MBone (Score:3, Informative)

      by Graymalkin ( 13732 )
      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.
    • MBone is not specifically dedicated to multicasting. MBone just refers to the fact that the routers are multicast enabled. It is just laid on top of Internet2 [internet2.edu].

      The MBone FAQ can be found here [columbia.edu]. The page is a bit old but the information is pretty much correct.

      Re-designing IP is more trouble than it is worth. First off, it would require deployment everywhere. So either 1) you upgrade every router, computer, etc. along the paths that need to use it or 2) you end up doing tunneling across IP anyway. Second, it works (or at least mostly works :) and provided everybody employs some sort of congestion control, it works quite nicely.

      The core problem is just that you have to make everybody play nice in the network which is what the IETF is trying to do. At the same time, you don't need the overhead of TCP (sending/resending lost/late packets). There has already been quite a bit of work on making UDP-based protocols that are TCP-friendly. The problem here is just choosing what attributes to use and what the messages going back and forth should be.

      Don't forget that anyone can participate in the IETF working groups. All you have to do is subscribe to the mailing list of the SIP working group [ietf.org] and you can add to the discussion.
  • I imagine that there are already some well designed applications and protocols for streaming video, and audio over UDP with congestion control; if there is not, then we need them. What we do not need, is 'in band' transfer of blobs over IM networks. What IM networks should be doing, is using the solutions to these problems that are already available. For example, how about a standard interface and process for negotiating an audio or video session via an out of band system? (for example, set up a multicast group, bring up an audio/video encoder and stream UDP over mbone. Another example, if you want to transfer a blob, have the receiver open up a socket and dump the file to the socket, or open one up yourself and have them connect to you. If you need to send a file to someone who is offline, send it as an email attatchment or upload it to a web/ftp server and pass the other user a URL to it. Using in band transfer for blobs is not a good thing; it puts load on servers, re-invents congestion control and error correction mechanisms that we already have, increases protocol overhead, and isn't P2P neccessarily (as some IM networks transfer via IM server [jabber,ICQ]). All we need is an agreed upon method for negotating out of band transfers, and a set of best of breed applications for particular tasks.
  • Instead of sending the content of the email message over the network, why not send only a "link" to the content.

    If/when the receiver wants the message, they would download it, but only if/when they wanted it.

    Spam would be less of an issue, at least it wouldn't take up your hard drive space. (unless you were fooled into clicking on it)

    Another benefit would be perfect receipts, the sender could determine who actually downloaded the message.

    Maybe a new mail protocol that could mix in some P2P technology. It could help for multiple recipients of the same content, once they successfully downloaded the content, they too can serve portions of it to the other potential receivers.

  • The main issues (Score:5, Interesting)

    by maggard ( 5579 ) <michael@michaelmaggard.com> on Monday January 14, 2002 @07:27PM (#2838963) Homepage Journal
    There's really three issues here:
    1. Online chat in it's various forms is popular.
    2. Folks are starting to use chat clients to send files to eachother.
    3. 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:

    1. Directory Services: How to find and connect to folks.
    2. Interoperability: How to negotiate settings & protocols between various clients.
    3. 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'd say there's some room for controversy too.

      All the candidate protocols for multimedia Internet instant messaging require some kind of proxy or ALG in every NAT device. Everyone hates NAT-- especially the IAB-- but a ridiculous number of people are relying on the facilities that NAT provides (home networks on residential IP service, and address realm independency). The current favorite, i.e. SIMPLE, seems much less NAT-friendly to me than the others.

      Coincidence, or conspiracy? If you're one of those executives in "the already shaky ISP market," then you probably hate NAT for completely different reasons than the IAB. Any multimedia instant messaging protocol that drives up the cost of purchasing, provisioning and managing a subscriber's NAT device might just give you the sort of leverage over home networking that you've been pining away for since the breakup of the Monopoly.

      Of course, I could just need to switch to decaf...

      --
    • you know, though i use IM,its really not anything other than low latency email and and ftp client/server. all they want to do now is add voice and video (and these would use different protocols and ports than the text and file transfers) the benefit of a unified standard would be that you could simple use an email address as the common identifier, then any isp could set up their chat server (just ike ppl have irc and email servers) your chat buddies then directly connect to you, and you become virtual client/servers the programs would run ftp file transfers off one port, text messages off another, and voice/video communications of yet another port all you isp does is act as a sort of dns for you IM client, so people log on to their isp's server and fire up their browser, email client, and IM client all using the same web standards why wouldnt this work?
  • by Thomas Charron ( 1485 ) <twaffle@gma i l .com> on Monday January 14, 2002 @07:42PM (#2839017) Homepage
    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 not going to type up a large dissertation about the this topic; I simply want bring this question to the forefront of your mind. Why is it necessary to wrap up so many different protocols with different goals into a single, all-encompassing protocol? What is the benefit of such an endeavor? What is wrong with simply passing URI's, which are text-encodeable, between IM's to start up separate connection processes?

    /dcc mynick senduri unreal://myhost.mydomain.tld:22244
    /dcc mynick senduri voip://myhost.mydomain.tld:30001

    Or if one must really have a generic way of specifying things, use a generic protocol designator:

    /dcc senduri udp://myhost.mydomain.tld:20001

    The response might look something like:

    /dcc yournick geturi 2

    Why must we encapsulate everything? It's starting to sound like such a protocol would rendure existing firewall QOS and traffic management strategies useless. If you can encapsulate all of your traffic through one IM client, you effectively have a firewall/router-piercing tool.

    I really don't see other advantages to this that are practicle or prudent.

  • I think perhaps many posters are missing the point here. TCP is an obvious choice for traffic with congestion control built in. But with the increasingly firewalled nature of the Internet, most of us have noticed how much of a pain it can be for services to automate file transfers. I think what these engineers want to do is figure out a good way of automating file transfers that doesn't have so many problems with firewalls, or will automatically work given the particular network configuration if the text-sending messaging protocol can get through.
  • by 8bit ( 127134 )
    Could someone please explain how a new IM protocol could POSSIBLY help? Isn't this a problem with the routers? Fix the routers, and you'd never have a problem with bandwidth hogs ever again.
  • I dont know about the whole "swamping the internet" part of the articale, but as far as AOL users go, i work tech support for a company (think big "Q") and sooo many times these AOL ppl call up because there "mic" dosent work, and you have to explain that voice is going over the "i n t e r n e t" on a 56K modem, and there just talking to ppl that live across town. *sigh* alexander graham bell where are you now?
  • On the border routers of the major backbone...

    Cisco[config]> int ser0/0
    Cisco[config]> shutdown

    Replace ser0/0 with whatever type of link AOL might have to the router should it not be some type of serial link.

    Boom, no more bandwidth problems.
  • How is sending mp3's over IM threatening to bring the internet to it's knees? If people didn't send them over IM they'd get them other ways, do IM protocals differ that much from standard web browsing and ftping that more bandwidth is used or something? Besides the plurity of aol users use aol's network, not the internet.
    • If people didn't send them over IM they'd get them other ways...

      Yes but IM makes it so easy that the usage would increase dramatically.
  • I can fix that problem right now.

    *runs over to the AOL internet uplink*

    ******SNIP*****

    Problem solved.

    It's not like AOLers contribute anything useful to the internet anyways
    • by danheskett ( 178529 ) <danheskett@gm[ ].com ['ail' in gap]> on Monday January 14, 2002 @11:46PM (#2839992)
      It's not like AOLers contribute anything useful to the internet anyways

      What an amazing misconception.

      Its easy to say they contribute nothing. But in fact, they contribute one important thing. Its not good Usenet posts, insightful email, strong opinions, or useful chat.

      They, do, however, subsidize the rest of us. Think of it like this.

      AOL has 22 million or so subscribers, paying about 24.95 a month. That's 548.9 Million per month. Multiply that by a year, and you get 6586.8 Million per year. Thats 6.5 Billion.

      How does that benefit me and you?

      I have Time Warner cable modem service, which ROCKS. My typical bandwidth is 2 megabits downstream and about 512 kilobits upstream. I have a virtually static IP (same for many many many many months), no restrictions on ports/etc, and best yet its like $40 a month.

      I know for a fact that Time Warner loses money from me. Bandwidth cannot be purchased from any source for the price I pay. If I only use 2 gb a day it has been a light day.

      So I am fine with AOL-TW dial-up/lame crippled DSL users paying for part of my bandwidth.

      Its a great deal as long as you can get it. And when the situation changes, thats fine too. But till that day - screw 'em.
      • It's not like AOLers contribute anything useful to the internet anyways
        What an amazing misconception. Its easy to say they contribute nothing. But in fact, they contribute one important thing. Its not good Usenet posts, insightful email, strong opinions, or useful chat. They, do, however, subsidize the rest of us. Think of it like this.

        Plus, like Microsoft, they provide a focal point for geeks everywhere to unleash their fury. Without that, the internet would implode as millions of geeks' heads exploded in frustration.

        Not that they would miss us.

  • by PMan88 ( 467902 )
    kinda offtopic, but when the hell is aohell gonna make it so thrid party aim clients can read peoples' away messages without pissing them off by iming them when they are gone? adium beats the pants off of the official client except for this
  • I'd be surprised if this article has any factual basis concerning IETF at all.

    SIP is for signalling only. Media info is included as SDP, which is independant of SIP.

    Just because the signalling takes place via UDP has nothing to do with how the media is transferred. Perhaps new media types need to be added to SDP which would have the flow control mechanism.

    SIP is still the way to go for the signalling part.
  • "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."

    Then the IETF should definitely not get involved.
  • by Archfeld ( 6757 ) <treboreel@live.com> on Tuesday January 15, 2002 @12:58AM (#2840288) Journal
    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.
  • How come nobody seems to be getting it. The problem isn't DCC sends between clients. The problem is high bandwidth data payloads using a signaling protocol rather than a regular transfer protocol. This stems from the oversight in the SIP protocol saying it can carry any sort of data over either TCP or UDP. So if you've got a ton of users all logging on at the same time sending UDP SIP packets over your network (MP3s and Divx movies for instance) it is going to fuck you up hardcore. Same if IM clients add stuff like voice and video as attachments sent over said SIP protocol. All it takes it one jackass to make an IM client that does all of its data transfer through the SIP protocol to make everyone have a bad day. It isn't just AOLs problem since they're using the same network infrastructure everybody else is using for everything else they use it for. So now the IETF is trying to get a better data transfer protocol to go along with SIP so some jackass doesn't take down a MAE because a bunch of people behind it sent a terabyte of UDP packets.

Mommy, what happens to your files when you die?

Working...