Re: Do ATM-based Exchange Points make sense anymore?
> Interesting points, and although orthogonal to the analysis in "Do > ATM-based Internet Exchange Points Make Sense Anymore?", I am including > these in the appendix to show these alternate views of the world. Am I > missing any of the major (fact-based) views? > There is this "small" thing that higher speed ATM interfaces are not actively being developed. It´s very hard to come by STM16 ATM interface on a router with STM64 being non-existent on both switches and routers. This is not due technological barriers but commercial reality. ATM would be going away faster if DSLAM´s wouldn´t be there increasing the traffic, but because of the extensive investments to ADSL gear, it´ll be there in 5, probably 10 years time. Because of the above reason, there is no point in setting up an ATM based exchange today. The first one here which was built 1996 is being retired by the end of year, and the other probably sometime next year. Pete
looking for benchmarks for campus and metropolitan networks
Hi Folks, I do an increasing amount of work with municipal electric utilities and local governments that are building community-wide MANS. The technology of choice is starting to be gigabit ethernet. I'm trying to pull together some benchmarks, or at least rules of thumb, for capacity planning - and I figure that large campus networks are a good place to start. So... to those of you who manage large campus or corporate networks, and particularly those of you running gigE as a campus backbone, do you have any rules of thumb regarding: - average/peak bandwidth per desktop - average/peak bandwidth per workgroup-level switch - how much bandwidth to provision between your campus network and your backbone POP(s) - etc. And... can you suggest any reference sources (books, web sites, email lists, etc.) that focus on design issues for very large campus networks? Thanks very much, Miles Fidelman ** The Center for Civic Networking PO Box 600618 Miles R. Fidelman, President & Newtonville, MA 02460-0006 Director, Municipal Telecommunications Strategies Program 617-558-3698 fax: 617-630-8946 [EMAIL PROTECTED] http://civic.net/ccn.html Information Infrastructure: Public Spaces for the 21st Century Let's Start With: Internet Wall-Plugs Everywhere Say It Often, Say It Loud: "I Want My Internet!" **
Re: Praise to XO's Security/Abuse
On 04:36 PM 8/30/02, John M. Brown wrote: > > >Jason at XO's security/abuse staff. Very helpful chap Indeed he is. Which is why I'm totally mystified about why rfc-ignorant insists that my domain doesn't have a working abuse address. I would privately email the admin at rfc-ignorant about this problem, but, well (see below) jc >From: Mail Delivery Subsystem <[EMAIL PROTECTED]> >Subject: Returned mail: User unknown >Message-ID: <[EMAIL PROTECTED]> >Errors-To: <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Auto-Submitted: auto-generated (failure) >X-UIDL: 59729 > >The original message was received at Mon, 26 Aug 2002 16:53:15 -0400 (EDT) >from adsl-208-201-244-240.sonic.net [208.201.244.240] > > - The following addresses had permanent fatal errors - ><[EMAIL PROTECTED]> > > - Transcript of session follows - >... while talking to narn.megacity.org.: RCPT To:<[EMAIL PROTECTED]> ><<< 550 5.7.1 <[EMAIL PROTECTED]>... Message rejected because the >connecting host (wellington.concentric.net) does not have abuse contact - >see www.rfc-ignorant.org >550 <[EMAIL PROTECTED]>... User unknown > > - Original message follows - > >Return-Path: <[EMAIL PROTECTED]> >Received: from Erwin.vo.cnchost.com (adsl-208-201-244-240.sonic.net >[208.201.244.240]) > by wellington.cnchost.com > id QAA27406; Mon, 26 Aug 2002 16:53:15 -0400 (EDT) > [ConcentricHost SMTP Relay 1.14] >Errors-To: <[EMAIL PROTECTED]> >Message-Id: <[EMAIL PROTECTED]> >X-Sender: [EMAIL PROTECTED] >X-Mailer: QUALCOMM Windows Eudora Version 5.0 >Date: Mon, 26 Aug 2002 13:55:30 -0700 >To: [EMAIL PROTECTED] >From: JC Dill <[EMAIL PROTECTED]> >Subject: Fwd: Returned mail: User unknown >Mime-Version: 1.0 >Content-Type: text/plain; charset="us-ascii"; format=flowed > >Can you explain why rfc-ignorant thinks my domain doesn't have a working >abuse address? > >jc
Praise to XO's Security/Abuse
Jason at XO's security/abuse staff. Very helpful chap Solved a problem with a downstream client of theirs that was pounding a network I help out Yes, I know off topic, but more on topic as this list SHOULD be about people HELPING people do good in these difficult times. YMMV, but I'm happy. Have a great day John Brown Chagres Technologies, Inc
Re: Do ATM-based Exchange Points make sense anymore?
At 01:13 PM 8/9/2002 -0700, Bill Woodcock wrote: > > Personally, I don't believe that ATM is 'bad' for > > shared-fabric exchange point. I mean, it works, and solves several > > problems quite easy: a) it's easily distributed via SONET services to > > folks who are not next to the ATM switch, b) it makes interconnection > > between networks safer (ie, not dealing with broadcast issues on a > > ethernet nap), c) virtual PI connections are easily accomplished, > d) there > > are varying degrees of interconnection speed (agreeably, less > important), > >All of the above are true of frame relay as well, which has the additional >benefit of not being funamentally incompatible with data networking. :-) You guys might find this interesting I'd like to share the more common "Religious debate points" regarding ATM-based vs. Ethernet-based IXes that I heard during the walk throughs (about 50 so far) of this paper (v1.6): -- ATM Advocate: First off, make sure you mention that ATM solves the key problem with "Broadcast Domain Internet Exchanges". Broadcast Domain Issues refers to problems when all ISP attachments are on the same Ethernet segment. Broadcast storms and other anomalies caused by one attached customer can adversely affects all others. Ethernet-based IX operators try and solve this problem administratively with MOUs Memorandum of Understanding (see the Appendix of the http://www.linx.net/joining/mou.thtml for an example of this) but it is solved in ATM by the private nature of PVCs, yielding a more stable peering infrastructure. Ethernet Advocate: Ethernet-based IXes can address these "Broadcast Domain" issues technically via private VLANs and direct cross connects between members. The "nature" of ATM as you describe it has a high overhead associated with it, specifically, by statically allocating bandwidth to a peering session with a historically spiky cyclical traffic characteristic. This static allocation of bandwidth prevents the multiplexing benefits of aggregation of lots of peering traffic sources. In addition to Ethernet-IXes being generally less expensive than ATM-based IXes, Ethernet interfaces are generally less expensive. This reduces the total peering costs, breakeven points, and increases the attractiveness of the Ethernet-based IX and therefore its likelihood of succeeding. Finally, Ethernet is what ISPs know, it is what they love. This ubiquity of and familiarity with Ethernet reduces the costs of operation, since operations folks only need to know how the Ethernet stuff works. ATM Advocate: Most Ethernet-based IXes primarily use the default LAN and are therefore subject to the "Broadcast Domain" issues. Ethernet may be less expensive but it is not shaping the traffic as ATM does. You pay for that functionality and stability. As for the operations argument, naturally one technology is easier to support than multiple technologies. This isn't a specific fault of ATM or Ethernet but rather and indication that choosing one and sticking with one is advantageous. Ethernet Advocate: In the Ethernet-based IX model, private cross connects allow one to scale beyond OC-12, the maximum reasonable capacity of ATM. The OC-48 ATM cards cost $250K, making it unreasonably expensive for the exchange of Internet Peering traffic. At the same time, the Ethernet-based model allows collocated folks to interconnect at Gigabit Ethernet, 10-GigE, whatever the peers choose. These direct connects are typically not allowed (for policy reasons) to occur at collocated ATM IXes. And PVCs are not the same things as a PNI as there are active electronics in the middle, some thing that can break, obscure troubleshooting, and limit flexibility with respect to interconnect types. Interesting points, and although orthogonal to the analysis in "Do ATM-based Internet Exchange Points Make Sense Anymore?", I am including these in the appendix to show these alternate views of the world. Am I missing any of the major (fact-based) views? Bill
RE: Broadening the IPv6 discussion
Iljitsch van Beijnum [mailto:[EMAIL PROTECTED]] wrote: > On Fri, 30 Aug 2002, Jeroen Massar wrote: > > > > > Maybe the p2p vendors should implement IPv6, it might also > > > > take a while until RIAA finds them again :-) > > > > Then I hope they'll implement RFC 3041, otherwise the RIAA > > > will go on a massive MAC address hunt... > > > Hmm a MAC... and then (sweet, dude) ? > > I still don't get it why that would be a problem, simply because: > > - one can change your IP by hand and/or automagically (RFC > 3041 like you > > mentioned) > > - MAC's can be changed (ifconfig hwaddr... ) > > Yes, but rebooting each time you change the MAC address for > your windows box gets somewhat tiresome after a while... With NT/2k/XP one can simply disable/enable netcards so that wouldn't be a problem. > > And then still.. they know that 'something/one' from a > certain /48 did > > 'something'. > > Ok, first of all: it was a joke. I guess I should have included a :-) Smileys always help. > Second: that the record industry might think it's a good idea > has little > bearing on it being actually a good idea. I have no trouble > believing they > would subpoena ethernet card sales records from stores to find out MAC > addresses to go after people who trade MP3s if they thought > there was a 1% > chance it would do their cause any good. And it might, since > most PC users > don't know what a MAC address is, let alone how to change it. > > > So what, if you pay at a store with your VISA or AMEX or simply your > > bankcard. > > That company holds at least your accountnumber, let's crossreference > > that. > > Never heard of cash? Internet shopping, most of my day-to-day food-supplies, big acquisitions happen using plastic; cash is that annoying stuff that fills my pants and gets spended too quickly when I pulled it out of the ATM. > (BTW your post wout be easier to read if the lines were < 80 chars.) Oops ;) > > Same thing (IMHO ;) as the IP address thing, it pops up at several > > places and they > > can do many statistical stuff with it for behaviour research, buy styles > > etc. > > Yes. I use a static address that is easily correlated with lots of > real-life info about me, and I'm not always happy about that. Not always indeed, but I personally don't mind most of the time though. Also you are probably familiar with the dutch law for personal information registration in which at least dutch companies/organisations have to register themselves if they keep information about persons. Email-lists/access-logs/crossrefs could quite possibly fall under this law, so every company retaining these informations would be in violation of a law ;) > > ipv6 [-p] gpu UseAnonymousAddresses [yes|no|always|Counter] > > that's how you turn that stupid feature off, it is annoying IMHO and > > quite useless as > > Why is it stupid, annoying and useless? Stupid comes from the annoying&useless parts (again IMHO :). Annoying because one needs to update his/her reverse every x seconds And I like to have a static IP with a corresponding reverse which identifies me as me. If somebody wants to track me or whatever google around, mailinglist archives etc tell more than my IP and I don't see anybody (okay there are bound to be people) complaining about google mirroring+indexing their sites (hail robots.txt ofcourse) Greets, Jeroen
Re: building a better route reflector
> Why don't we dump IP routeing and have one big supernet on one big > bridge peice of ethernet? Wouldn't life be simple! It would still be difficult to tune traffic without my /24 annoucements being heard. It could work if we used global 802.1q tags instead of ASN's, although it probably would help if we add a couple octets to the VLAN ID. The equivalent of as_path could be stored similar to IP RR, moving processing overhead to a lower layer. We would also need a global tag registry, which I would be happy to host in our world-class NOC. It's a great place to work, and stays toasty warm even on cold winter days. Dalph "Wiggum" Roncaster principal, WiggumwerksGhostNetwork.com div. of Mad Clue Consulting Group Get your free encrypted email at https://www.hushmail.com
RE: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at
On August 29, 2002 at 11:54 [EMAIL PROTECTED] (Jeroen Massar) wrote: > Never been in the city (those places where more than 100k people live) > now have you ? Born and raised in NYC, lived the past 25+ years in Boston, spent some time in between living in LA. If there are any other questions I can help you with please, please don't hesitate to ask. -- -Barry Shein Software Tool & Die| [EMAIL PROTECTED] | http://www.TheWorld.com Purveyors to the Trade | Voice: 617-739-0202| Login: 617-739-WRLD The World | Public Access Internet | Since 1989 *oo*
RE: ospf problems?
Besides, it's funny. Where would NANOG be w/o the satire/sarcasm (Besides having a higher SNR.) Derek > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of > Paul Vixie > Sent: Friday, August 30, 2002 2:54 PM > To: [EMAIL PROTECTED] > Subject: Re: ospf problems? > > > [EMAIL PROTECTED] writes: > > > Why do we let RIchard Sexton get away with posting this kind of > insulting > > drivel to the list? > > in my specific case, it's because i've configured my user interface in a > way that allows me to live on an internet that does not have certain > people > in it. (no, my .procmailrc is not for sale, so go make your own.) > > in the general case, "we let" this happen because there is no procedure > for > excluding folks from "the list" on any basis, including "insulting". > -- > Paul Vixie
Re: ospf problems?
[EMAIL PROTECTED] writes: > Why do we let RIchard Sexton get away with posting this kind of insulting > drivel to the list? in my specific case, it's because i've configured my user interface in a way that allows me to live on an internet that does not have certain people in it. (no, my .procmailrc is not for sale, so go make your own.) in the general case, "we let" this happen because there is no procedure for excluding folks from "the list" on any basis, including "insulting". -- Paul Vixie
RE: Broadening the IPv6 discussion
On Fri, 30 Aug 2002, Jeroen Massar wrote: > > > Maybe the p2p vendors should implement IPv6, it might also > > > take a while until RIAA finds them again :-) > > Then I hope they'll implement RFC 3041, otherwise the RIAA > > will go on a massive MAC address hunt... > Hmm a MAC... and then (sweet, dude) ? > I still don't get it why that would be a problem, simply because: > - one can change your IP by hand and/or automagically (RFC 3041 like you > mentioned) > - MAC's can be changed (ifconfig hwaddr... ) Yes, but rebooting each time you change the MAC address for your windows box gets somewhat tiresome after a while... > And then still.. they know that 'something/one' from a certain /48 did > 'something'. Ok, first of all: it was a joke. I guess I should have included a :-) Second: that the record industry might think it's a good idea has little bearing on it being actually a good idea. I have no trouble believing they would subpoena ethernet card sales records from stores to find out MAC addresses to go after people who trade MP3s if they thought there was a 1% chance it would do their cause any good. And it might, since most PC users don't know what a MAC address is, let alone how to change it. > So what, if you pay at a store with your VISA or AMEX or simply your > bankcard. > That company holds at least your accountnumber, let's crossreference > that. Never heard of cash? (BTW your post wout be easier to read if the lines were < 80 chars.) > Same thing (IMHO ;) as the IP address thing, it pops up at several > places and they > can do many statistical stuff with it for behaviour research, buy styles > etc. Yes. I use a static address that is easily correlated with lots of real-life info about me, and I'm not always happy about that. > ipv6 [-p] gpu UseAnonymousAddresses [yes|no|always|Counter] > that's how you turn that stupid feature off, it is annoying IMHO and > quite useless as Why is it stupid, annoying and useless? Iljitsch van Beijnum
RE: AT&T NYC
> > On Fri, 30 Aug 2002 [EMAIL PROTECTED] wrote: > > > > I would definately not recommend route reflection or a confederation in a > > > network with such a small number of BGP routers: > > > In spirit of the above, I suggest you also do not have maintenance window, > > forget about re-checking configs, enable to do the simpliest commands, and > > of course let everyone try debugging any problems by typing random commands > > into your routers. After all, your network consists of only 4 routers. > > Ok, but how is _not_ using route reflection or a confederation similar to > the above??? I fail to see how using confederations makes it complicated. In fact, should a network consist of two or above pops, and has more than one exit point, confederations are an excellent way to give one ability to fine tune traffic distribution. Alex
Re: Broadening the IPv6 discussion
Hello; My personal feeling is that on-line extreme gaming will be a very good "killer ap" for ISP's selling broadband. HOWEVER, IMHO the current ASM with MSDP will _not_ support one million+ (*,G) groups. ASM is limited in its interdomain growth potential at present, in both IPv4 and IPv6, and there is no real consensus on how to move forward. SSM could support 1 million (S,G) only groups, but then, unless you are going to have a combinatorial N! group explosion, you will need to impose some sort of hierarchical nature on the game (say, you only comminicate with the people (entities?) you are interacting with. Regards Marshall Eubanks Petri Helenius wrote: > [EMAIL PROTECTED] wrote: > >>you can go hybrid, like >>- client connects to server for game playing info (like location on the >> map, inventory and stuff) >>- client will talk with each other directly for video/voice-chat >>even with this, server load/traffic will be decreased. >> > > This is exactly what I also had in mind. This would get 1:10 benefit > in bandwidth and actually enable this kind of activity. > >>i still don't understand why you say multicast is mandatory. >> >> > Most consumer connetions (where this is feasible anyway) are asymmetric, > having 256k-1.5Mbps downstream and 128k-512k upstream. A decent video stream > represents 128k to 384k of bandwidth. If you have a small number, say eight > players in a game, you'll end up sending the stream seven times unless > you do multicast. You probably don't have the upstream bandwidth to accommodate > that unless you're lucky to sit on top of a new housing development with > fiber in the basement. > > The next logical step to this discussion is what happens to multicast routing > when one million gamers setup half a million *,G and a few million S,G pairs. > Add a zero if it makes the excersise more interesting. Keep in mind that > one million gamers playing is less than what the network currently has at any given > moment. > > Pete > -- Regards Marshall Eubanks This e-mail may contain confidential and proprietary information of Multicast Technologies, Inc, subject to Non-Disclosure Agreements T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : [EMAIL PROTECTED] http://www.multicasttech.com Test your network for multicast : http://www.multicasttech.com/mt/ Status of Multicast on the Web : http://www.multicasttech.com/status/index.html
RE: Broadening the IPv6 discussion
Iljitsch van Beijnum wrote: > On Fri, 30 Aug 2002, Petri Helenius wrote: > > > > What might happen is that ISPs start using IPv6 for their > (as example) DSL > > > services to work around addressing problems. But that is > not a userdriven > > > demand. > > > Maybe the p2p vendors should implement IPv6, it might also > take a while > > until RIAA finds them again :-) > > Then I hope they'll implement RFC 3041, otherwise the RIAA > will go on a massive MAC address hunt... Hmm a MAC... and then (sweet, dude) ? I still don't get it why that would be a problem, simply because: - one can change your IP by hand and/or automagically (RFC 3041 like you mentioned) - MAC's can be changed (ifconfig hwaddr... ) And then still.. they know that 'something/one' from a certain /48 did 'something'. So what, if you pay at a store with your VISA or AMEX or simply your bankcard. That company holds at least your accountnumber, let's crossreference that. Same thing (IMHO ;) as the IP address thing, it pops up at several places and they can do many statistical stuff with it for behaviour research, buy styles etc. But then again, as long as one wants to be directly addressed you will always be 'trackable' some how. Or are you changing bank-accountnumbers, emailaddresses every 10 minutes? Which pops again into the SPAM problem, where we'd (or at least me ;) would rather be capable of verifying who is sending stuff. If one then put that into a log, one could trace people too. And the bigger MX's could do that now too ofcourse... Btw: http://www.microsoft.com/technet/treeview/default.asp?url=/TechNet/prodt echnol/winxppro/proddocs/sag_IP_v6_add_Utils.asp ipv6 [-p] gpu UseAnonymousAddresses [yes|no|always|Counter] that's how you turn that stupid feature off, it is annoying IMHO and quite useless as usually one is on the same /64 (or /48) so one is quite traceable already. Ofcourse if you got a laptop and carry it around the world with the same EUI-64 one is quite easily indentifyble, but then still, so what; they know you go to cool places ;) Greets, Jeroen
RE: AT&T NYC
On Fri, 30 Aug 2002 [EMAIL PROTECTED] wrote: > > I would definately not recommend route reflection or a confederation in a > > network with such a small number of BGP routers: > In spirit of the above, I suggest you also do not have maintenance window, > forget about re-checking configs, enable to do the simpliest commands, and > of course let everyone try debugging any problems by typing random commands > into your routers. After all, your network consists of only 4 routers. Ok, but how is _not_ using route reflection or a confederation similar to the above??? Iljitsch
RE: AT&T NYC
> > > Practices.) > > > OK, then hand me a clue and explain why ruing an iBGP mesh with 3-4 > > routers is so bad (seeing as Bassam Halabi didn't in his book). > > I would definately not recommend route reflection or a confederation in a > network with such a small number of BGP routers: you add lots of > complexity, potential for less optimal routing (and possibly obscure > implementation problems) and the only thing you gain is not having to > the existing BGP routers when you add a new one. In spirit of the above, I suggest you also do not have maintenance window, forget about re-checking configs, enable to do the simpliest commands, and of course let everyone try debugging any problems by typing random commands into your routers. After all, your network consists of only 4 routers. Alex P.S. In case it not clear, the above paragraph is not what you should ever do.
Re: Broadening the IPv6 discussion
On Fri, 30 Aug 2002, Petri Helenius wrote: > > What might happen is that ISPs start using IPv6 for their (as example) DSL > > services to work around addressing problems. But that is not a userdriven > > demand. > Maybe the p2p vendors should implement IPv6, it might also take a while > until RIAA finds them again :-) Then I hope they'll implement RFC 3041, otherwise the RIAA will go on a massive MAC address hunt...
RE: AT&T NYC
On Thu, 29 Aug 2002, Ralph Doncaster wrote: > > Ralph, you > > have never failed to amaze me with your love for WCP (Worst Current > > Practices.) > OK, then hand me a clue and explain why ruing an iBGP mesh with 3-4 > routers is so bad (seeing as Bassam Halabi didn't in his book). I would definately not recommend route reflection or a confederation in a network with such a small number of BGP routers: you add lots of complexity, potential for less optimal routing (and possibly obscure implementation problems) and the only thing you gain is not having to reconfigure the existing BGP routers when you add a new one. If this is really your main concern, you can always make one router a route reflector but still keep the full IBGP mesh. Then you can add a new BGP router and you just have to configure a session with the reflector and save setting up IBGP sessions with the rest of the BGP routers for when you have some time on your hands. (Obviously you have a problem if the reflector fails before you get around to this.) I'm pretty sure this will earn me a place on someone's worst practices list, though. :-) Iljitsch van Beijnum
Re: Broadening the IPv6 discussion
Kurtis Lindqvist wrote: > > What might happen is that ISPs start using IPv6 for their (as example) DSL > services to work around addressing problems. But that is not a userdriven > demand. > I'm already aware of installations where IPv6 gets you globally routable connectivity and IPv4 gets you NATted. No mentionable impact on IPv6 traffic. Maybe the p2p vendors should implement IPv6, it might also take a while until RIAA finds them again :-) Pete
Re: Broadening the IPv6 discussion
> > with IPv6 (without NAT), server can just introduce client A's address > > to B, and let them video-chat directly. so game operators will be > > able to reduce the size of central server, and traffic to server will > > be decreased. so for game operators, IPv6 has major (commercial) > > benefit. > > Remember that for this to happen, you also need multicast. And since IPv4 Petri I think the point is that you actually don't need multicast to do it. For it to scale - yes. But not to do it. I guess that is also partly why multicast has not taken off.. - kurtis -
Re: ospf problems?
> i awoke from my hibernation to this mail. what's going on? Why do we let RIchard Sexton get away with posting this kind of insulting drivel to the list?
Re: Broadening the IPv6 discussion
> > >Driver #1 : Sell p00rn via IPv6 only. > > > >Sad but true. Content and use is all there is. > > Remember that multicast never happened either. > How much it would take to "sponsor" free content over multicast to > get it deployed. Don´t know if this would be approvable for government > subsidies though. I am not sure it has to be free. It just has to be available. As long as there is no valuable content in v6 that I can't get in v4 there will be no user drive to change. What might happen is that ISPs start using IPv6 for their (as example) DSL services to work around addressing problems. But that is not a userdriven demand. - kurtis -
Re: building a better route reflector
On Fri, 30 Aug 2002, Neil J. McRae wrote: > > > > > > > Running two routing protocols is too much of a hassle. I think I would > > rather use static routes, and synchronize routers using rsync, diff, and > > patch. Our NOC has several 286s running Xenix that could act as servers > > for this. > > > > This would eliminate the hassle of running OSPF, ISIS, or RIP. Does > > anyone know of a Tier-1 for under $30/Mbps that would run something like > > this instead of BGP? I'd love it if we didn't need any routing protocols. > > > > Why don't we dump IP routeing and have one big supernet on one big > bridge peice of ethernet? Wouldn't life be simple! This would appear to be the way things are moving actually in some ways think ethernet on MPLS, who needs connections to IXPs any more when we can all share one or have one big global IXP?! ;)
Re: routing architectures ( was Re: AT&T NYCrouting )
> > Um. Set up more than one reflector > > So how many is enough? I would think 3 is a minimum to come close to the > reliability/redundancy of OSPF. I fail to see what reflectors have to do with stability (except for the obicous human errors and configuration mistakes). Reflectors and confederations is more to help with scaling. And I would then expect the number of BGP speaking routers to be up around 10-15-20. It doesn't make much sense below that (unless you are playing with the number of routes on boxes). Last I fail to see what the number of reflectors have to do with correlation to a IGP? - kurtis -
Re: Broadening the IPv6 discussion
[EMAIL PROTECTED] wrote: > > you can go hybrid, like > - client connects to server for game playing info (like location on the > map, inventory and stuff) > - client will talk with each other directly for video/voice-chat > even with this, server load/traffic will be decreased. This is exactly what I also had in mind. This would get 1:10 benefit in bandwidth and actually enable this kind of activity. > > i still don't understand why you say multicast is mandatory. > Most consumer connetions (where this is feasible anyway) are asymmetric, having 256k-1.5Mbps downstream and 128k-512k upstream. A decent video stream represents 128k to 384k of bandwidth. If you have a small number, say eight players in a game, you'll end up sending the stream seven times unless you do multicast. You probably don't have the upstream bandwidth to accommodate that unless you're lucky to sit on top of a new housing development with fiber in the basement. The next logical step to this discussion is what happens to multicast routing when one million gamers setup half a million *,G and a few million S,G pairs. Add a zero if it makes the excersise more interesting. Keep in mind that one million gamers playing is less than what the network currently has at any given moment. Pete
Re: Broadening the IPv6 discussion
[EMAIL PROTECTED] wrote: > > one area that might be of interest is internet gaming. nowadays, > all gaming client will connect to the central server, and all traffic > from client to another client has to go through the central server This is a feature. It makes cheating a lot of harder if you don't have access to the binaries to hack around to give yourself superpowers against the other players. > for video-chat between clients (because of NAT, it is not possible for > clients to communicate directly). > it has two major issues: > - game operators has to prepare giant server that can handle thousands > of clients > - traffic to server will be severe, if we are to support client-to- > client video-chat Video and voice even represents a valid application (and has done so for 5+ years) for true peer networking. > > with IPv6 (without NAT), server can just introduce client A's address > to B, and let them video-chat directly. so game operators will be > able to reduce the size of central server, and traffic to server will > be decreased. so for game operators, IPv6 has major (commercial) > benefit. Remember that for this to happen, you also need multicast. And since IPv4 multicast never happened, how will IPv6 multicast? If you don't have multicast, the client would have to replicate the packets and that would lead to upstream congestion since most consumer connections are assymetric in nature. Pete
Re: RIAA
RIAA Web site hack allows music file downloads http://www.nwfusion.com/news/2002/0829riaahack.html heh... -- Tomas Daniska systems engineer Tronet Computer Networks Plynarenska 5, 829 75 Bratislava, Slovakia tel: +421 2 58224111, fax: +421 2 58224199 A transistor protected by a fast-acting fuse will protect the fuse by blowing first.
