Re: Diffserv service classes
Sean Donelan wrote: On Sat, 20 Nov 2004, Vicky wrote: interesting read at: http://qbone.internet2.edu/papers/non-architectural-problems.txt There is a long history of problems. But Internet2 also shows a success for Diffserv, namely there is demand for a worse effort. Are a dozen differnt classes useful to a network operator? Hardly, the greatest demand so far has been for cheap if not free packets which your transit provider can drop if he so decides. Bandwidth that is used for redundancy planning, etc. Queuing/diffserv is useful on thin (sub 2Mbps) edge links. Pete
Re: who gets a /32 [Re: IPV6 renumbering painless?]
Paul Vixie wrote: more importantly though is your /40 example. ipv6 has enough address space in it to be able to give a /32 to every household on the planet, including a reserve for the ones without electric power or phones. giving out /40's If we ever make contact to some other civilization out there, do they have to run NAT? Pete
Re: who gets a /32 [Re: IPV6 renumbering painless?]
--On 21 November 2004 11:59 +0200 Petri Helenius [EMAIL PROTECTED] wrote: If we ever make contact to some other civilization out there, do they have to run NAT? Nah. Jim Fleming tells me they're running IPv8 (ducks) Alex
large multi-site enterprises and PI prefix [Re: who gets a /32 [Re: IPV6 renumbering painless?]]
I think this is important point that needs to be called out explicitly. On Sat, 20 Nov 2004, Iljitsch van Beijnum wrote: On 19-nov-04, at 17:58, Stephen Sprunk wrote: these organizations tend to have multiple sites (as you indicate above) but they generally do not have real connectivity between those sites. This means a single large prefix won't do them much good, and basically they're no different than a bunch of smaller single-site organizations. Don't have real connectivity? I've personally worked with dozens of Fortune 500 companies that have internal FR/ATM networks that dwarf ATT, UUnet, etc. in the number of sites connected. Thousands of sites is common, and tens of thousands of sites in some cases. Do you not consider these networks real because each site may only have a 16k PVC to talk to corporate? That's right. If you need internet access, you need it to be faster than 16 kbps. As far as I can tell, it's pretty rare for an organization of this size to have their own IP network that they use to connect all their sites to the global internet, for the simple reason that leased lines, framerelay or ATM capacity is generally more expensive than IP connectivity. So a single large address block is of little use to such an organization, unless they get to announce more specifics all over the place. If we reword the last sentence to include the use of ULA addresses, to be like: So a single, globally routable large address block is of little use to such an organization, unless they get to announce more specifics all over the place. This seems to imply several things: - when having lots of sites, you typically want to obtain local Internet connectivity, because transporting all the traffic over links or VPNs is a pretty heavy business * though at least the smallest sites are also likely to be solely obtain their connectivity using VPNs through centralized firewalls etc. - you don't want to backhaul all the traffic in the internal network / VPNs, so you'll either need to announce a lot of more specifics or use IP addresses from local internet providers - giving those big enterprises globally routable PI will make it much more lucrative for them to request allowing the more specifics from their upstreams, etc., thus getting us to the more specific mess. Therefore, if we'd like to to prevent the more specific multihoming/traffic engineering mess we have with v4, most of those big enterprises don't really seem to need globally routable PI space, provided that they can already use ULAs if they want. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: Central Europe Web hosting recommendations
Hi Michael, Thanks for all the on and off list replies. I will be condensing the input into a doc to submit to the person actually needing that info... I will share that doc upon private request... Thanks again to the list.. You got my personal email also i hope? Just checking, since you didnt give a reply back. I would also be interested in the dokument you made, so if you are willing to share it with us that would be nice. Thanks, Raymond.
Re: Diffserv service classes
On Sun, 21 Nov 2004 00:09:31 -0500 (EST) Sean Donelan [EMAIL PROTECTED] wrote: On Sat, 20 Nov 2004, Vicky wrote: interesting read at: http://qbone.internet2.edu/papers/non-architectural-problems.txt There is a long history of problems. But Internet2 also shows a success for Diffserv, namely there is demand for a worse effort. Are a dozen differnt classes useful to a network operator? Dear Sean; You raise an interesting point. There are some emerging wide bandwidth applications (eVLBI is one, particle physics experiments are another) where bandwidth demands are high but the value of each individual bit is low. (In VLBI it is typical for each bit sent to only contain about 10^-3 to 10^-4 bits of actual information.) As a result, these applications are (or can be made to be) very tolerant of packet losses. eVLBI, for example, would take 1 Gbps with 25% loss over 100 Mbps with no loss any day. An Internet standby worse than best effort QOS would be easy to implement, according to router vendors, and there seems no reason why ISP's would not want to propagate such a COS flag. This is not really a new idea. When I was programming on a mainframe as a student (back when dinosaurs walked the Earth) I routinely used a service class that only gave me CPU when there were no other uses for the system. This would extend the same idea to the Internet, and it fits with with the QBone experience that it's hard to impossible to raise priorities interdomain, but easy to lower them. Would commercial operators support a reduced cost standby system with a do not queue or drop these bits first policy flag attached ? I would be curious to receive re-world experiences or suggestions off list, and would be glad to summarize later on list. Regards Marshall Eubanks P.S. Note that such a system would easily interoperate with non-participating networks, who could either drop such traffic entirely (it is worse than best effort, after all), or forward it with normal priority, as they see fit.
Re: who gets a /32 [Re: IPV6 renumbering painless?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2004-11-19, at 12.46, Jeroen Massar wrote: On Fri, 2004-11-19 at 12:15 +0100, Iljitsch van Beijnum wrote: On 18-nov-04, at 18:02, Jeroen Massar wrote: Larger enterprises probably consist of 200 'sites' already, eg seperate offices, locations etc. Thus they can, after becoming a LIR and getting an ASN, which most of the time they already have, easily get a /32. Jeroen, this is nonsense and you know it. It is not nonsense as long as 'multi6' doesn't have a solution to the problem, but as politics go above getting solutions... I am not sure I follow you here? Multi6 in D.C decided to spin of the protocol work in a new WG under the Internet Area. I think that for the last few years, multi6 has moved forward as fast as anyone could ask. - - kurtis - / Co-chair multi6 -BEGIN PGP SIGNATURE- Version: PGP 8.1 iQA/AwUBQZ9b8qarNKXTPFCVEQLV2wCg+XtQqEH/oo0QjoT4a3LHag8YHlwAoP2I L/o/iD6ydT1aXpIz5xYR3MLO =s/g5 -END PGP SIGNATURE-
Re: who gets a /32 [Re: IPV6 renumbering painless?]
if the ipv6 routing table ever gets as large as the ipv4 routing table is today (late 2004 if you're going to quote me later), we'll be in deep doo. *WHEN* the ipv6 routing table gets as large as the ipv4 routing table is today (late 2004, when you quote me later) it won't be a problem. As a matter of fact, I would bet that Cisco , Juniper, and any other edge/core router manufacturer are banking on this happening. if it were just the routers, then you're apparently expecting the same owners to need better ones, and i agree that a router vendor would probably look very favourably on such a development. however, i'm counting on new owners needing their first routers, and an O(1e6) sized routing table doesn't make any difference there -- a router vendor might be even happier, in fact. but it's not just the routers, it's churn. it's always noon somewhere. the stability of the distributed system called the global routing table is directly proportional to its size. the number of participants in that system, each of whom must build their own model of the system using only the messages they get from direct neighbors, cannot usefully exceed *some* maximum for any given total number of discrete destinations. if you think that the number of available participants leads to a maximum stable table containing O(1e6) destinations, then you should be arguing for a /20 minimum allocation size. If you think the table in question has O(1e10) destinations then you'd be arguing for a /30 minimum allocation size. But to consider a /40 minimum allocation size, you'd be saying that you thought a table containing O(1e12) discrete destinations, and i think that's false in two ways -- first, the current distance-vector approach used by BGP just won't scale to O(1e12), and second, i don't think that you think that there are enough participants who want to own routers to make such a table size necessary. someone asked about my sole benefit comment, so i'll amend it. it's not a global cost and sole benefit, but it is a global cost to the other ends with the preponderance of benefit (for a prefix) falling on the owner of the prefix. so it's not one-sided but it is certainly an assymetric benefit with a symmetric cost. mr. doran argued for many years that routing table slots should be auctioned or leased. i never did and still do not agree with him, but his starting assumptions weren't and aren't my point of disagreement. -- Paul Vixie
Re: Diffserv service classes
Hi, Less-than-best effort traffic as implemented via the Internet2 Scavenger Service (see: http://qbone.internet2.edu/qbss/ ) never really took off; for example, see http://netflow.internet2.edu/weekly/20041108/#dscp which notes that Scavenger Service (DSCP=8) tagged traffic makes up less than 1% of all octets and less than 1% of all packets. One can argue chicken-and-egg (e.g., had it been supported on the commodity Internet, it would have been more successful), but I think the bottom line reality was that because -- Internet2 was/is uncongested, and because -- the typical university user of I2 pays $0/Mbps used anyhow, the motivation for users to tag traffic as Scavenger was typically non-existent (offering a discount from a price of zero is hard unless the model would involve PAYING people who generate less-than-best-effort traffic, a model which strikes me as, well, somewhat unsustainable/politically difficult). A network administrator at a site might unilaterally tag all traffic of a particular type as less-than-best-effort, but again, unless there is congestion, that tagging would be to no effect. Regards, Joe St Sauver ([EMAIL PROTECTED]) University of Oregon Computing Center
Re: who gets a /32 [Re: IPV6 renumbering painless?]
On 20-nov-04, at 18:34, Stephen Sprunk wrote: Don't have real connectivity? That's right. If you need internet access, you need it to be faster than 16 kbps. Who said the only purpose of IP was to connect to the Internet? Not me. But if you don't connect to the internet you don't contribute to the global routing table so there is no issue. :-) The point is, that these days applications such as mail and web are sufficiently heavy that you can't even run them cost effectively over dial up (wasting your employee's time costs more than the fatter line) let alone less. So a single large address block is of little use to such an organization, unless they get to announce more specifics all over the place. In my experience, they will announce the aggregate from all hub sites plus more-specifics for that hub and the sites directly connected to it. Traffic that comes into the wrong hub due to prefix length filters (or Internet outages) is back-hauled inside the corporate backbone. It would be interested to see some good statistics on this stuff. However many enterprises any of us has seen from the inside, it's still unlikly to be a statistically relevant sample.
Re: who gets a /32 [Re: IPV6 renumbering painless?]
On 20-nov-04, at 21:45, Paul Vixie wrote: for all these reasons, large or multihoming endsystems will need V6 PI allocations and at some point the RIRs are going to have to define/allow this. I find your attitude in this regard disturbing, especially as: (note that i'm not speaking for arin, nor as a member-elect of arin's board of trustees, i'm just another bozo on this bus.) You're bascially saying that you and people like you are so important that you deserve to receive benefits that go against the public good. While you're high and dry, the hoi polloi can renumber while at the same time suffering increased ISP costs because of the unnecessarily high hardware costs created by all those PI prefixes. In other words, today's equivalent of let them eat cake. It also shows contempt for the IETF, as you reject all possible alternatives to PI out of hand. there is no possibility that any enterprise where i am responsible for planning or design will ever run PA addresses out to the desktop -- it makes multihoming impossible, which would leave me at the mercy of a single provider's uptime, and a single provider's pricing. Work is underway to remedy this. However, if the RIRs decide to open up PI in IPv6, people will take the quick fix and there won't be any push to get the (admittedly) more complex but more scalable solutions to these problems off the ground.
Re: who gets a /32 [Re: IPV6 renumbering painless?]
for all these reasons, large or multihoming endsystems will need V6 PI allocations and at some point the RIRs are going to have to define/allow this. I find your attitude in this regard disturbing, especially as: (note that i'm not speaking for arin, nor as a member-elect of arin's board of trustees, i'm just another bozo on this bus.) You're bascially saying that you and people like you are so important that you deserve to receive benefits that go against the public good. actually, i'm just trying to keep my role as member-elect of arin's BoT separate from my role as an internet citizen. as it turns out, arin's BoT does not have a policy formation role. when this issue comes up in PPML or the AC, i'll speak up, but i'll be explicitly hatless when i do. While you're high and dry, the hoi polloi can renumber while at the same time suffering increased ISP costs because of the unnecessarily high hardware costs created by all those PI prefixes. In other words, today's equivalent of let them eat cake. you are drastically misunderstanding my hopes, my goals, and my role. It also shows contempt for the IETF, as you reject all possible alternatives to PI out of hand. i never rejected all possibilities, just the ones i've personally studied so far. i'm also on record as saying that the easiest time to have fixed this was before the current IPng approach was annointed; now we're playing catchup. even you in your multi6 role ought to be wishing that more had been done before IPv6 was cast in stone. there is no possibility that any enterprise where i am responsible for planning or design will ever run PA addresses out to the desktop -- it makes multihoming impossible, which would leave me at the mercy of a single provider's uptime, and a single provider's pricing. Work is underway to remedy this. However, if the RIRs decide to open up PI in IPv6, people will take the quick fix and there won't be any push to get the (admittedly) more complex but more scalable solutions to these problems off the ground. somehow i don't think that's going to sway wal-mart's thinking at all, but i do look forward to a lively debate next time this comes up on PPML. the codification of the current approach as IPng in spite of objections raised at that time amounted to a recommendation of let them eat NAT.
Re: who gets a /32 [Re: IPV6 renumbering painless?]
Thus spake Iljitsch van Beijnum [EMAIL PROTECTED] On 20-nov-04, at 18:34, Stephen Sprunk wrote: Don't have real connectivity? That's right. If you need internet access, you need it to be faster than 16 kbps. Who said the only purpose of IP was to connect to the Internet? Not me. But if you don't connect to the internet you don't contribute to the global routing table so there is no issue. :-) The point is, that these days applications such as mail and web are sufficiently heavy that you can't even run them cost effectively over dial up (wasting your employee's time costs more than the fatter line) let alone less. That assumes the company wants their employees using web or email, or that there are even humans at a site to begin with. Pipeline control systems, weather stations, cash registers, credit card machines and ATMs, warehouse inventory scanners, stock exchanges, etc. have no need to _directly_ talk to the outside world. People in customer-facing roles, like those at banks or airports, are not supposed to be surfing the web or even doing email at work. Many companies are still using green-screen apps or graphical applications that have a measured per-terminal average of under 1kbps; I ran into one company tunneling 9600bps serial over X.25 over IP -- ugly, but it worked for thousands of terminals. However, all of these low-bandwidth hosts in far-off lands talk to a corporate datacenter somewhere, perhaps their own or a vendor's or customer's, and those hosts often talk to several other hosts who might also need (or at least have) access to the Internet. The options are NAT, ULAs, or PI space; total cost of implementation seems lowest for ULAs. In my experience, they will announce the aggregate from all hub sites plus more-specifics for that hub and the sites directly connected to it. Traffic that comes into the wrong hub due to prefix length filters (or Internet outages) is back-hauled inside the corporate backbone. It would be interested to see some good statistics on this stuff. However many enterprises any of us has seen from the inside, it's still unlikly to be a statistically relevant sample. An unfiltered BGP feed should give you stats on what's quoted immediately above. If you want numbers of publicly-invisible hosts, even if you knew who to ask most would refuse to answer for security reasons or require an NDA. My best guess, having been on the inside at a few dozen enterprises, is that they number in the high millions to low tens of millions today. In five years, it'll be in the mid tens of millions as more and more new hardware comes with IP connectivity built-in and legacy apps are gradually updated. S Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking
Re: Diffserv service classes
No doubt what you say is true, however, the typical eVLBI site is not part of the Internet2 (and also doesn't need the TCP aspects of the Scavenger service). There are certainly applications and users out there that would like to use all of the bandwidth possible, but do not need to step on other, more bit sensitive, services. Regards Marshall On Sun, 21 Nov 2004 10:04:53 -0800 (PST) Joe St Sauver [EMAIL PROTECTED] wrote: Hi, Less-than-best effort traffic as implemented via the Internet2 Scavenger Service (see: http://qbone.internet2.edu/qbss/ ) never really took off; for example, see http://netflow.internet2.edu/weekly/20041108/#dscp which notes that Scavenger Service (DSCP=8) tagged traffic makes up less than 1% of all octets and less than 1% of all packets. One can argue chicken-and-egg (e.g., had it been supported on the commodity Internet, it would have been more successful), but I think the bottom line reality was that because -- Internet2 was/is uncongested, and because -- the typical university user of I2 pays $0/Mbps used anyhow, the motivation for users to tag traffic as Scavenger was typically non-existent (offering a discount from a price of zero is hard unless the model would involve PAYING people who generate less-than-best-effort traffic, a model which strikes me as, well, somewhat unsustainable/politically difficult). A network administrator at a site might unilaterally tag all traffic of a particular type as less-than-best-effort, but again, unless there is congestion, that tagging would be to no effect. Regards, Joe St Sauver ([EMAIL PROTECTED]) University of Oregon Computing Center
Re: Diffserv service classes
Hi, #There are certainly applications and users out there that would #like to use all of the bandwidth possible, but do not need #to step on other, more bit sensitive, services. They might want to, but unfortunately we (the Internet2 community as a whole) have had limited success in helping them routinely achieve higher throughput for bulk transfers. Again refering to http://netflow.internet2.edu/weekly/20041108/ see Table 1: -- The median throughput for bulk TCP flows is still less than 3Mbps. -- The 95th percentile for bulk TCP flows is still less than 15Mbps. There is an I2 end-to-end performance initiative designed to improve those numbers, but at root, because most of the PCs that scientists and students work from are not shipped from the vendor pre-tuned for high throughput, average throughput numbers remain low. When PC vendors begin to read http://www.psc.edu/networking/perf_tune.html or http://www.web100.org and offer higher education special SKU's preloaded with OS's tweaked per those approaches, then, maybe, we'll see average performance routinely increase and congestion become a pragmatic issue. Until then, it will be routine to see most Abilene connectors run at only a fraction of their potential capacity, e.g., see: http://stryper.uits.iu.edu/abilene/aggregate/html/report-2004-11-20.html Shrug. Regards, Joe
Re: who gets a /32 [Re: IPV6 renumbering painless?]
Somebody said: if the ipv6 routing table ever gets as large as the ipv4 routing table is today (late 2004 if you're going to quote me later), we'll be in deep doo. *WHEN* the ipv6 routing table gets as large as the ipv4 routing table is today (late 2004, when you quote me later) it won't be a problem. Agreed. When the IPv6 table has as many routes as today's IPv4 table, we'll need four times the storage; Moore's Law says, as long as that doesn't happen within 36 months, it's not a problem. I haven't seen anyone (recently) predict IPv6 adoption will be anywhere near that fast, much less faster. Thus spake Paul Vixie [EMAIL PROTECTED] but it's not just the routers, it's churn. it's always noon somewhere. the stability of the distributed system called the global routing table is directly proportional to its size. the number of participants in that system, each of whom must build their own model of the system using only the messages they get from direct neighbors, cannot usefully exceed *some* maximum for any given total number of discrete destinations. ... first, the current distance-vector approach used by BGP just won't scale to O(1e12), Probably not, even if router vendors start using reasonably modern processors. and second, i don't think that you think that there are enough participants who want to own routers to make such a table size necessary. As a point of reference, today in IPv4 there are 16k origin-only ASes. Assuming reasonably sane RIR policies, we can expect -- even with the issue of one PI prefix per AS -- that there would be 16k end-site PI routes today, with linear growth similar to the current allocation rate of ASNs. This is not even remotely a problem until well after we have to switch to 32-bit ASNs; in fact, the situation will be far better than what we will likely have with IPv4 at that point. mr. doran argued for many years that routing table slots should be auctioned or leased. i never did and still do not agree with him, but his starting assumptions weren't and aren't my point of disagreement. The idea has obvious appeal, but it seems like a clear case of the cure being worse than the illness once you consider the logistical and technical requirements. S Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking
Netranger
Would anyone with Netranger IDS experience please contact me off-list? Cheers, -Chris
Real-world Force10 opinions?
Can anyone offer any real-world Force10 E-series opinions? L3, 10GE, GE, POS, BGP, and IS-IS is what we will be evaluating them for. Any opinions, gotchas or other advice would be appreciated. Looking through the archives, I see that there have a been a few similar questions in the past year or two, but no replies. I can summarize to the list if others are interested. thanks bill
Re: who gets a /32 [Re: IPV6 renumbering painless?]
Paul Vixie wrote: But to consider a /40 minimum allocation size, you'd be saying that you thought a table containing O(1e12) discrete destinations Except that we are talking about allocations out of 2001::/16 which yeilds a about 1e7 prefixes, not subtracting the huge chunks taken by /32 allocations. The idea with using a /16 for initial allocations is that we don't screw up the entire /0 before we know what we are doing. In the scope of a /16, I think /32 and /40 allocations are sized appropriately. The real question is why exchange points and root servers are allocated /48's. It would make sense to use a different prefix length to reduce the temptation for other /48's to pollute the table.
Re: large multi-site enterprises and PI prefix [Re: who gets a /32 [Re: IPV6 renumbering painless?]]
So a single large address block is of little use to such an organization, unless they get to announce more specifics all over the place. This seems to imply several things: - when having lots of sites, you typically want to obtain local Internet connectivity, because transporting all the traffic over links or VPNs is a pretty heavy business this is an assertion which many have claimed is false. based on empericial evidence. - you don't want to backhaul all the traffic in the internal network / VPNs, so you'll either need to announce a lot of more specifics or use IP addresses from local internet providers this is also an assertion based on false premise. Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: Stupid Ipv6 question...
On 20 Nov 2004, at 19:13, Kevin Oberman wrote: In any case, if the prefix length is 64, routing is done in the CPU. Engineers at Juniper seem to be telling me that this is definitively not the case for their M- and T-series routers. Which routers were you referring to? Joe
Could somebody from shaw.ca contact me please?
I think we have a networking / connectivity issue between your mailservers and our netblock 205.158.62.0/24, and quite a few shawcable users are writing to us, to complain about it. thanks --srs -- suresh ramasubramanian [EMAIL PROTECTED] gpg # EDEDEFB9 manager, security antispam operations, outblaze limited
