Slashdot Mirror

← Back to Domains

Domain: sprint.net

Stories and comments across the archive that link to sprint.net.

Comments · 8

  1. Re:fairness by Anonymous Coward · · Score: 0 · on Bittorrent To Cause Internet Meltdown

    Single-source multicast works just fine on the Intardnet. (see for example Sprint's multicast page. Sprintlink has several heavy (hundreds of Mbps average) native multicast users.

    The only thing in the way SSM deployment is that most home routers simply do not talk native multicast on the WAN side.

    What does not work well is (S,G) state in routers for large numbers of sources and groups. So a fan-out mode from a small number of sources (which is one popular usage mode for BitTorrent) to an arbitrarily large group is a reasonable fit for SSM; if the group size is zero, the outgoing packets are dropped very close to the source. If the group size is one or greater, the source simply transmits a single copy and the network maintains the fan-out tree. Lost packets towards the leaves of the fan-out tree can be recovered later (on a repeat broadcast) or via an out of bound protocol.

    This works, but is inefficient for the recipients of the data compared to a CDN or a substantial set of local caches, and is also inefficient for the single source compared to that of BitTorrent and other P2P distribution mechanism if there are often relatively small numbers of users.

    However, SSM is more efficient for "live" content to a variable audience, but there is no obvious way to make it particularly competitive with other means of distributing recorded/regeneratable/static content.

    Substituting a full-blown use of multiple-sender/multiple-group multicast for P2P applications would drown all parties in control traffic and state. Remember that for unicast routers (even household routers) only have to know about the direction in which to foward a packet based on its destination IP address, and these can be summarized into e.g. a default address. For multicast, per-interface group membership must be tracked, as must the arrival direction of traffic; the arrival and departure of sources must be distributed globally to facilitate this. The "exactly one copy" fan-out model is computationally intensive for large numbers of sources and nontrivial sets of sources.

    Finally, as you note, TCP is good at bulk data transfer. It is also good at avoiding congestion. Streaming multicast is not. Either you send very slowly so as not to cause congestion at the slowest bottleneck, or you are pretty much guaranteed to be increasing congestion somewhere. Slowing down the whole pool of users just because someone on a dial up modem talking SLIP or PPP joins a tree is not a great idea. Neither is sending at 100Mbps if you expect users to join across normal DSL lines.

  2. Looking glasses by mbone · · Score: 1 · on Sprint Cuts Cogent Off the Internet

    If you are having trouble with internet connectivity and suspect this is the issue you can :

    Use traceroute if you can or

    Go to the various looking glasses to see if you can get to your site (or the other site) from Sprint, Cogent, or an intermediate point.

    The Cogent Looking glass

    The Sprint looking glass.

    The Traceroute.org list.

  3. Re:Fabulous for scientific use... by hr+raattgift · · Score: 1 · on Review of Seagate's 750Gb Hard Drive
    The MBONE, if it had ever been adopted


    Multicast technology has advanced considerably since the days of MBONE.

    David Meyer, University of Oregon, and at various times with Sprint and Cisco, and on the Internet Architecture Board, spent a considerable amount of time herding cats in the development and deployment of scalable native multicast forwarding across large-scale ISP infrastructure.

    Here is one result: no-fee Sprintlink native multicast (see also the FAQ).

    Several other ISPs and university networks also exchange multicast network layer reachability information (mBGP), implying support for native multicast.

    Currently most multicast deployment favours large dynamic groups of listeners subscribing and unsubscribing to traffic originated from a relatively small set of sources, rather than generalized many-to-many conversations. With current technology many-to-many "oligocasting" is most efficiently emulated by a single sender receiving (via unicast) messages which are then multicast to a tree of subscribers. This is generally referred to as SSM, Single-Sender Multicasting, which is suitable for the modern Internet in which switching equipment performance (or cost, if you will) is bounded by dynamic adaptiveness (control messaging, routing) rather than the amount of traffic being switched. SSM is also a good fit for applications similar to cable-TV-like broadcasts or distribution of large sets of data from a primary centre to subsidiary or replica centres.

    MBONE's performance was bounded by the tunnelling and especially replication performance of the UNIX workstations that were the majority of MBONE's routers, as well as by the obsolete DVMRP and MOSPF multicast WAN routing protocols which were used even across ISP and other network boundaries.

    not every institution looking at the data will be interested in the same data at the same time


    You could combine SSM with a "TIVO-like" function, saving the multicasted data locally and extracting what you want, when you want it, from your local copy. If your shared multicast distribution tree significantly reduces the sender's bandwidth by moving your 100x duplication into "the network" such that you approach only one copy of a given datum sent once from the sender to the sender's ISP, it's a win. If you also approach one copy of a given datum sent once down any given branch of the tree rooted at the sender and branching at Internet routers between the sender and every receiver, you make a good trade-off, as the cost of small numbers of copies performed in routers (possibly one per interface) distributes well and for heavily-subscribed Single Sources the cost is likely to be smaller than the cost of carrying multiple copies of the same traffic.

    With your example the question is whether the cost of locally recording likely-to-be-interesting data received via multicast is greater than the cost of smearing out any duplicate requests (from you or any of the other 100 sites) over time. Most of the cost in the latter "video-on-demand" style approach is borne by the primary sender.
  4. Re:One other thing I thought of by hr+raattgift · · Score: 1 · on Nielsen Adapting To Modern TV-Watching

    Imagine what would happen if ISPs started supporting IP multicast.

    Some do. Ask yours. There are two principal availability models for native multicast that I know of. Both require asking your ISP to talk sparse-mode PIM and to exchange multicast NLRI with you via BGP. At least one large scale provider charges a nominal fee for doing this at all, at and least one large scale provider does this for free but caps the amount of multicast traffic you can send without making an extra arrangement.

    The principal problems with multicast are operational (not many people know how to set up and debug it, although Sprint's mulitcast pages are an OK start. However, IP multicast is only reasonably scalable when you restrict yourself to single-source trees, but on the other hand SSM (with PIM-SM and BGP) is coincidentally the least operationally difficult approach.

    The main engineering problem is that you inevitably create state in routers for each source that is being listened to (you can optimize out state for silent and unsubscribed sources) in all the routers from the source to each destination. In practice there is "collateral damage" state in most routers in a network in between sources and subscribers. This is cut down somewhat by using Rendezvous Points and distributing those using anycast and MSDP, which moves work from border and intermediate routeers into the RPs. This works well, but incurs a cost which increases as multicast traffic increases. (Essentially, you can drown your RP with traffic. You can distribute RP work, but that then increases control traffic on the routing or source-discovery planes, and there will be some limit.)

    In short, the model which scales well enough to make multicast essentially "free" beyond the cost of IP connectivity, is limited by the number of multicast transmitters. The number of subscribers is barely a concern, and the sender's bandwidth is unlikely to pose an engineering issue at any speed less than a gigabit per second.

    Making material with lots of FEC or which is loss-tolerant available via SSM is cheap and easy. An obvious application would be live TV content, and that could take advantage of multiple parallel groups -- clients would "slow start" by subscribing to a low-bandwidth stream, then graduate to other (or more) streams if reception works well. Likewise, if whatever stream they are subscribed suffers from too packet loss, the source can unsubscribe it and use a lower-bandwidth/lower-quality one instead.

    From the originator's perspective, this is exceptionally easy: originator announces the sources and just blast multicast packets out to its ISP. The ISP will simply drop any traffic in groups that aren't subscribed-to by someone. The originator is thus limited by the bandwidth out to the provider, and nothing else.

    If the originator has loss-tolerant content to begin with, or a loss-tolerant encoding (with lots of forward-error-correction or redundancy for example), the originator doesn't even have to cope with network losses. This means the audience can be *huge*.

    A file distribution model is plausible using this type of system... you would just "build in" the retransmissions that inevitably would be required because of network losses. The problem is in feedback: you probably don't want to transmit if there are no listeners; you probably want to transmit at about the greatest minimum speed at which there is no congestion-related loss observed by your subscribers; you probably want to tune your retransmissions/redundant transmissions based on client needs. All of this requires a communication from receivers back to the source.

    If there are lots and lots of receivers, you risk drowning the source in feedback.

    If there are very few receivers, then this is a very heavyweight mechanism for sending data to them. Moreover, if the receivers can also be transmitters, you will get better performance by ha

  5. Re:This has been discussed...... by namelessone99 · · Score: 2, Informative · on Major Flaw Found In Cisco IOS Devices

    Check out this for a full listing of the sprint maintenances. They are upgrading every router across the globe!

  6. Re:DoS and Spam by BlueUnderwear · · Score: 2 · on ISP Forced Out of Business by DoS
    Depends, if a spammer is trying to sell a real product they should be perfectly possible to track down.

    Exactly. Just ask their credit-card processing company, they must have some place where they credit the money to.

    And even without this, on most spams, you have a sender IP to work with, which leads to an ISP, which theoretically has logs about who used that IP at the time the spam was sent. However, the problem is, many, ISPs don't really care, and consider it more cost efficient to just file mails to abuse into /dev/null .

    But I imagine, a court order would really help to encourage them to act, unless of course they didn't keep any logs in the first place. However, spam is often such a minor offense that nobody bothers to intend legal action against the offenders.

  7. good question by akb · · Score: 2 · on DSL Providers that Support Multicast & MBone?

    I think this is a very important question, thanks to Slashdot for finally posting it. Users should demand multicast connectivity. A multicast enabled internet would dramatically lower the cost of delivering multimedia content, thus making a wider variety of content available. Currently, delivering multimedia to large numbers of users is quite expensive, preventing many from having access to large audiences.

    MSN used to offer multicast connectivity, I'm not sure when they stopped. Anyone know the story on this?

    A few things consumers can do:

    -if you are shopping for an ISP of any kind ask about multicast and try to get the question to get as high up the chain as possible.

    -Sprint offers free multicast connectivity to its ISP customers, if yours peers with them let them know this. (does Sprint offer multicast connectivity to its consumer grade customers?)

    -check to see if you've got multicast connectivity through this applet from multicasttech. If you are let other people know about your ISP, on forums like dslreports

  8. Re:MBone by jmilne · · Score: 1 · on Live Streaming Video?

    The MBone is still out there. Sorta. It's not really the same MBone that most of those web pages talk about, created with DVMRP tunnels and all. A lot of the major ISPs are starting to natively enable their networks for multicast with new protocols like PIM-SM, MSDP, and MBGP. With PIM-SSM coming up, it looks like we might finally have a really workable protocol to get multicast out there to the masses. Here's some sites for multicast information regarding ISPs.

    Most people who are doing video streaming via multicast end up going with Windows Media Server or Real Server. I think QuickTime is also multicast-enabled, but I haven't seen it used much. Another option is to go with Cisco IP/TV. Although most of their stuff says to use it in an enterprise network, I've seen it used for multicast video streaming on the MBone/Internet. Pretty good quality stuff... I've seen demos of DVDs streamed using it, and the quality was at least that of VHS.