With tunneling (which consequently allows VPNs), and dynamic routing, it is debatable as to whos geographics boudaries apply, if anyones.
Well maybe one day there will be HTTP extensions (or finger/DNS protocol extensions), allowing the client and the server to tell which law applies to it. "ApplyingCountryLaw: France".
Just raise the numbers of his example and you are back to being wrong that the solution is just more bandwidth.
30 KB is a bit extreme for a packet for which you want QoS. It makes no sense to increase the packet size to 3 MB, to get the feared 2.4 ms latency.
The ATM packet size was an advantage because they are "short". However this advantage vanishes because as network bandwidth increases much much faster than packet size, typical IP packets become "short" too.
An
ATM implementation can offer delay variation (jitter) guarantees whereas alternatives will not. This is not only
because of the fixed packet size but because it is a connection-based technology, so it will never make a guarantee
that it can't support.
RSVP with full support of IntServ specifications can make queueing guarantees, but I'm not aware they are pratical on real, wide, networks. But statistical guarantees on IP is exactly what DiffServ is attempting to do. Look at the "expedited forwarding" or "assured forwarding" PHB of DiffServ, for examples.
Also on the specific point:
It is a connection-based technology
How does it handle QoS with several hundred thousand of connections on a large network ? DiffServ idea is simple: they do aggregation, flow policying at the edges, and possibly use more bandwidth to make up for the latency added in the various paths.
We don't want to schedule individually the flows of 100000s of VC or of 1000s of VP in each switch, do we?
Re:Network Dynamism issues
on
Smart Routers
·
· Score: 1
While router based QOS is neat, it's really only a tiny step forward. We need IPv6 before QOS really
becomes a reality. Router based QOS is just no substitute for protocol based QOS.
Huh? QoS is integrated in a complete architecture.
You definitly don't need IPv6. Look at DiffServ for the architecture, network engineering are interested in using. Basically the network provider marks your packets at the edge, based on the contract you have with him (and the info you give him); your packets are routed through the other providers based on the contracts they have with each others. And that's it.
If you only want to have QoS on a 1 Mbps link between your sites at San Francisco and Chicago, you might also choose the same provider so that you don't need to switch back and forth between different providers backbones. How your packets are marked, how they are handled, how your excess packets are treated, and how much you pay is just a matter of contract with your provider in the DiffServ model.
MPLS/POS QoS still will not rival that of ATM b/c MPLS traffic will be all variable sized and at some points
these will need to be buffered and Jitter will increase even for high-QoS streams (take the instance where a
30,000B packet of priority x is just being transmitted and a 30B packet of priorty_greater_than_x is sent to an
egress port. that 30B packet will have to wait for the entire 30,000 B packet to be transmitted.).
This is a problem only if you have limited bandwidth. If you have high bandwidth (say 1 terabit), the delay for which the 30B packet will have to wait will be much less than the transmission delay: 24 ms at 1 Gbps, 24 microseconds at 1 Tbps (at which point the hardware architecture dominate the switching delay, not nessarily queueing).
Since bandwidth can increase but obviously the speed of light cannot be increased, I'm tempted to say ATM small packets are attempting to solve the wrong problem. ATM is only optionnal.
..fool you into thinking that the FBI is a God-like policing agency. They have the same problems,
short-sightedness and management of any other organization or business in the world. The only reason that
paranoid Slashdotters fear the FBI so much is because they themselves are less knowledgeable and organized.
Actually there are more than that. Because of their incompetence, innocent people have been sentenced death. Some have probably been actually executed (we don't know, since US don't accept any new element once the sentence has been executed).
You value privacy, but you relish posting other people's information? Doesn't that make you a bit of a...
hypocrit? Why, yes, I think it does.
No it doesn't. You said you don't care about personal information, he says he does. So he published your personal information, and he didn't publish his personal information. Since you don't care, this is a non-event.
I think it's in extremely poor taste to go around posting other
people's phone numbers on web sites that don't ever delete messages, though.
According to your theory, this isn't a problem at all. So are you implying this isn't quite right ?
Why would 8,000 identical boxes be difficult to administer? The guys that develop the monitoring software and
the install and upgrade processes are probably pretty smart cookies. But the actual maintence of the machines
could probably be handled by monkeys.
Well they don't even need 8000 identical boxes. All they need is hard-drive access (just IDE) and network card access.
I think about it: the instructions for handling a hardware failure in one of these machines is probably:
[...]
Or: replace instantly the machine with another random one. Put the system recovery CD in the drive. Let it reboot and try all the possible kernels/configurations until it boots successfully with IDE/network.
At the same time take the initial defective machine: split all the parts and insert them in place of corresponding components in others unused working machines. Throw away the part which doesn't work.
NT will handle this more efficiently than Linux, due to a superior
asynchronous I/O model. If you doubt this, look up some of the research reports on Unix i/o limitations. Linux
has a long way to go to reach the same performance levels.
It's well known NT is better in theory. Unfortunatly in practice this comes at a cost. So point out real research reports with real figures and real comparisons.
However, if you
run a proxy server and have logs to show that somebody else committed that crime through your proxy, you
have an alibi. If you just run a proxy but don't log, this alibi is much more shaky; you could just be running the
proxy to cover for crimes that you're actually committing from that computer.
You could, yes, however you might not as well, so there is no proof. So you should be considered innocent: just demonstrating that actually anyone from anywhere could use your proxy (which is easy), should be enough. Of course, you're guilty of something ranging to unknowningly helping a criminal to being a complice.
And NO! 'all
nodes should be mirrored by other nodes' is nonsense. Frequently downloaded files propogate geographically to where they are requested. Mirroring garbage is
ridiculous.
Hmm... That's the problem with caches. Last time I saw figures, the WWW cache had a 50% hit success. That's means that 50% of the time people would access document that are not in the cache. If most of them are on transient machines (such as off the night, 50% of the time), 25% of the time you won't be able to access the documents you wish. This is too high.
And if a 12-year-old girl produces a modified version of Emacs, and publishes it under terms that violate the GPL, the
FSF could sue to prevent her from distributing it -- not because she violated a contract with the FSF (since she can't
legally be bound by a contract), but because she is distributing the FSF's copyrighted material without permission.
I thought that Russ Nelson argument was shaky, but anyway the appropriate scenario is the following: the 12-year-old is injuried as a result of using the same GPL software, and her parents sue the FSF ? The only GPL recourse is to say that it is written in the license that there is no warranty, and that she was contractually bound to it when using the software. There is no copyright violation.
May not be the 70's anymore, but even with backups accidents do happen. I am not saying it ever would happen, I'm just saying it seems silly to actually
have a language where destroying all whitespace would destroy the code.
If you alter the source code, then it can be unusable. An accident that would only happen to change whitespace magically? This fear is referred as the "Alien whitespace eating nanovirus" in the Python community. The answer is that Pythoneers are so brave they don't fear this Damocles sword, and still go on using Python. Praise them!
The reason why it is not fully acceptable, and satisfies my curiosity into the language is that after working on projects where code is passed around many
different systems and version control, etc often times formatting gets botched. It happens, a lot.
The only problem is probably MS Visual Tools (and some other Windows editors) using Tab=4 spaces.
Configure them to be 8, or to use only spaces.
If you don't, mixing MSTools and (X)Emacs would be quite annoying anyway.
Can you point out another tool than an editor, that willingly would modify spacing ? It would mess multi-lines strings really bad.
The closest thing that I can think of is it's a design flaw.
It's a choice. Guido choosed to offer the Python programmers a clearer syntax, at the expense of people using broken tools.
Besides if you really want block based local parsing, use "pyident.py" or one of the other simple easy solutions.
But, it goes into the whole thing of: If the whitespace goes, the code is useless.
Yes. If you use crappy tools you're in big trouble. I have a solution: type the same code twice in two different editors, two different OS, two different tools, on two different computer. Do you find this too much a burden? Python programmers find too much a burden typing { } or begin/end again, and again, and again, and again, and again, and again, and again,... ad nauseam ; just in case someone, somewhere, might be uninformed enough to start using defective tools without a backup or a test.
I agree with you, how when you check in it should check the indentation.. or compile, whenever - and warn (not error, it isnt.) that your indentation sucks.
Badly indented Python code has 99% chances to fail
on parsing, with a SyntaxError.
I'd love to see something like:
Warning: hello.c, line 81: Your code is structured like a monkey wrote it. Please learn how to indent.
There are the options '-t' and '-tt':
-t : issue warnings about inconsistent tab usage (-tt: issue errors)
What?! Presumably you're saying that Linux wouldn't even have existed if the GNU kernel had been finished in 1992.
Okay, maybe, but I don't think the GNU kernel is even "ready" now! Or if so, quite recently... So, yeah, it seems as if
there was only an 8 year window of opportunity where Linux could have come about:)
Well, there was also the competition with FreeBSD/NetBSD (which was delayed due to the BSD license story).
I think you misspelled "Feel free to sit back on your lazy ass while somebody else designs and implements a fix - just
like they always do".
Yes, the people that are paid to engineer the Internet will solve the technical issue, and as always the gloomy predictions ala Metcalfe, will probably be proved wrong. Remember when the backbones were 56 Kbps (before 1988) and it was unthinkable to some people it won't collapse? Remember the T1 backbones until 1991, when Internet was doomed to be charged by volume?
Nowadays I have 1-5 Mbps download connection to major sites. Bandwidth is no longer a big issue? Now predictions are about explosions/wild changes of route tables (to be fair, this has been started a long time ago, along with with IPv4 unconceivably too small address space).
Slashdot Mirror
Well maybe one day there will be HTTP extensions (or finger/DNS protocol extensions), allowing the client and the server to tell which law applies to it. "ApplyingCountryLaw: France".
30 KB is a bit extreme for a packet for which you want QoS. It makes no sense to increase the packet size to 3 MB, to get the feared 2.4 ms latency. The ATM packet size was an advantage because they are "short". However this advantage vanishes because as network bandwidth increases much much faster than packet size, typical IP packets become "short" too.
An ATM implementation can offer delay variation (jitter) guarantees whereas alternatives will not. This is not only because of the fixed packet size but because it is a connection-based technology, so it will never make a guarantee that it can't support.
RSVP with full support of IntServ specifications can make queueing guarantees, but I'm not aware they are pratical on real, wide, networks. But statistical guarantees on IP is exactly what DiffServ is attempting to do. Look at the "expedited forwarding" or "assured forwarding" PHB of DiffServ, for examples.
Also on the specific point:
It is a connection-based technology
How does it handle QoS with several hundred thousand of connections on a large network ? DiffServ idea is simple: they do aggregation, flow policying at the edges, and possibly use more bandwidth to make up for the latency added in the various paths. We don't want to schedule individually the flows of 100000s of VC or of 1000s of VP in each switch, do we?
Huh? QoS is integrated in a complete architecture. You definitly don't need IPv6. Look at DiffServ for the architecture, network engineering are interested in using. Basically the network provider marks your packets at the edge, based on the contract you have with him (and the info you give him); your packets are routed through the other providers based on the contracts they have with each others. And that's it.
If you only want to have QoS on a 1 Mbps link between your sites at San Francisco and Chicago, you might also choose the same provider so that you don't need to switch back and forth between different providers backbones. How your packets are marked, how they are handled, how your excess packets are treated, and how much you pay is just a matter of contract with your provider in the DiffServ model.
This is a problem only if you have limited bandwidth. If you have high bandwidth (say 1 terabit), the delay for which the 30B packet will have to wait will be much less than the transmission delay: 24 ms at 1 Gbps, 24 microseconds at 1 Tbps (at which point the hardware architecture dominate the switching delay, not nessarily queueing).
Since bandwidth can increase but obviously the speed of light cannot be increased, I'm tempted to say ATM small packets are attempting to solve the wrong problem. ATM is only optionnal.
Actually there are more than that. Because of their incompetence, innocent people have been sentenced death. Some have probably been actually executed (we don't know, since US don't accept any new element once the sentence has been executed).
No it doesn't. You said you don't care about personal information, he says he does. So he published your personal information, and he didn't publish his personal information. Since you don't care, this is a non-event.
I think it's in extremely poor taste to go around posting other people's phone numbers on web sites that don't ever delete messages, though.
According to your theory, this isn't a problem at all. So are you implying this isn't quite right ?
Well they don't even need 8000 identical boxes. All they need is hard-drive access (just IDE) and network card access.
I think about it: the instructions for handling a hardware failure in one of these machines is probably: [...]
Or: replace instantly the machine with another random one. Put the system recovery CD in the drive. Let it reboot and try all the possible kernels/configurations until it boots successfully with IDE/network.
At the same time take the initial defective machine: split all the parts and insert them in place of corresponding components in others unused working machines. Throw away the part which doesn't work.
It's well known NT is better in theory. Unfortunatly in practice this comes at a cost. So point out real research reports with real figures and real comparisons.
Including something that's perfectly right.
You could, yes, however you might not as well, so there is no proof. So you should be considered innocent: just demonstrating that actually anyone from anywhere could use your proxy (which is easy), should be enough. Of course, you're guilty of something ranging to unknowningly helping a criminal to being a complice.
Same for me. I've just searched, I have 156 posts.
Period. End of story.
No, not every case of IP.
Period. End of story.
Hmm... That's the problem with caches. Last time I saw figures, the WWW cache had a 50% hit success. That's means that 50% of the time people would access document that are not in the cache. If most of them are on transient machines (such as off the night, 50% of the time), 25% of the time you won't be able to access the documents you wish. This is too high.
I thought that Russ Nelson argument was shaky, but anyway the appropriate scenario is the following: the 12-year-old is injuried as a result of using the same GPL software, and her parents sue the FSF ? The only GPL recourse is to say that it is written in the license that there is no warranty, and that she was contractually bound to it when using the software. There is no copyright violation.
If you alter the source code, then it can be unusable. An accident that would only happen to change whitespace magically? This fear is referred as the "Alien whitespace eating nanovirus" in the Python community. The answer is that Pythoneers are so brave they don't fear this Damocles sword, and still go on using Python. Praise them!
The only problem is probably MS Visual Tools (and some other Windows editors) using Tab=4 spaces. Configure them to be 8, or to use only spaces. If you don't, mixing MSTools and (X)Emacs would be quite annoying anyway.
Can you point out another tool than an editor, that willingly would modify spacing ? It would mess multi-lines strings really bad.
The closest thing that I can think of is it's a design flaw.
It's a choice. Guido choosed to offer the Python programmers a clearer syntax, at the expense of people using broken tools.
Besides if you really want block based local parsing, use "pyident.py" or one of the other simple easy solutions.
I agree with you, how when you check in it should check the indentation.. or compile, whenever - and warn (not error, it isnt.) that your indentation sucks.
Badly indented Python code has 99% chances to fail on parsing, with a SyntaxError.
I'd love to see something like: Warning: hello.c, line 81: Your code is structured like a monkey wrote it. Please learn how to indent.
There are the options '-t' and '-tt':
-t : issue warnings about inconsistent tab usage (-tt: issue errors)
And it will.
Well, there was also the competition with FreeBSD/NetBSD (which was delayed due to the BSD license story).
Yes, the people that are paid to engineer the Internet will solve the technical issue, and as always the gloomy predictions ala Metcalfe, will probably be proved wrong.
Remember when the backbones were 56 Kbps (before 1988) and it was unthinkable to some people it won't collapse? Remember the T1 backbones until 1991, when Internet was doomed to be charged by volume?
Nowadays I have 1-5 Mbps download connection to major sites. Bandwidth is no longer a big issue? Now predictions are about explosions/wild changes of route tables (to be fair, this has been started a long time ago, along with with IPv4 unconceivably too small address space).