Re: "Does TCP Need an Overhaul?" (internetevolution, via slashdot)
At 03:54 PM 05-04-08 -0500, Jorge Amodio wrote: outstanding compilation Hank, thanks !!! I suggest reading the excellent page: "High-Speed TCP Variants": http://kb.pert.geant2.net/PERTKB/TcpHighSpeedVariants Rgds -Jorge It is the result of the Geant2 SA3 working group. There is much more there than just TCP variants. Regards, Hank
Akamai/Speedera outages this weekend?
Anyone know anything about the Speedera (now Akamai) outages this weekend? https://cachecontrol.speedera.com/cgi-bin/cpurge.pl has been off and on unreachable since last night, which is causing fits for some parts of our application... of course, I have been able to find zero contact information for our account with speedera/akamai internally...anyone know anything? ..david --- david raistrickhttp://www.netmeister.org/news/learn2quote.html [EMAIL PROTECTED] http://www.expita.com/nomime.html
Re: Nanog 43/CBX -- Hotel codes etc
> Anyway -- I regard most of those warnings as quite overblown. I mean, > on lots of subway cars you stand out more if you don't have white > earbuds in, probably attached to iPhones. Midtown is very safe. Your > laptop bag doesn't have to say "laptop" on it to be recognized as such, > but there are so many other people with laptop bags that you won't stand > out if you have one. Subway crime? The average daily ridership is > about 5,000,000; there are on average 9 felonies a day on the whole > system. To quote a city police official I met, that makes the subways > by far the safest city in the world. That's probably an abuse of statistics. > Yes, you're probably at more risk if you look like a tourist. But there > are lots of ways to do that, like waiting for a "walk" sign before > crossing the street... (Visiting Tokyo last month was quite a shock to > my system; I had to unlearn all sorts of things.) Looking and acting like you belong is good advice in most circumstances. Act like the other monkeys. If you don't give someone reason to question you, they probably won't. Wait, oh, that's the guide book for infiltrating facilities ... ;-) ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
RE: Flow Based Routing/Switching (Was: "Does TCP Need an Overhaul?" (internetevolution, via slashdot))
> The flows are in those boxes, but only for stats purposes > exported with NetFlow/IPFIX/sFlow/etc. Apparently it was not > as fast as they liked it to be and there where other issues. > Thus what exactly is new here in his boxes that has not been > tried and failed before? Roberts is selling a product to put in at the edge of your WAN to solve packet loss problems in the core network. Since most ISPs don't have packet loss problems in the core, but most enterprise networks *DO* have problems in the core, I think that Roberts is selling a box with less magic, and more science behind what it does. People seem to be assuming that Roberts is trying to put these boxes in the biggest ISP networks which does not appear to be the case. I expect that he is smart enough to realize that there are too many flows in such networks. On the other hand, Enterprise WANs are small enough to feasibly implement flow discards, yet big enough to be pushing the envelope of the skill levels of enterprise networking people. In addition Enterprise WANs can live with the curse of QoS, i.e. that you have to punish some network users when you implement QoS. In the Enterprise, this is acceptable because not all users have the same cost/benefit. If flow switching lets them sweat their network assets harder, then they will be happy. --Michael Dillon
Re: "Does TCP Need an Overhaul?" (internetevolution, via slashdot)
outstanding compilation Hank, thanks !!! Rgds -Jorge
Time Warner NOC contacts.
If there is anyone from Time Warner NOC on this list, please contact me at [EMAIL PROTECTED] We are seeing issues with DNS caching inside the RR network. Thanks, Kirk Winkelman Positive Networks
RE: "Does TCP Need an Overhaul?" (internetevolution, via slashdot)
On Sat, 5 Apr 2008, Kevin Day wrote: > On Apr 4, 2008, at 8:51 PM, Paul Vixie wrote: >> >> What is really necessary is to detect just the flows that need to >> slow >> down, and selectively discard just one packet at the right time, but >> not more, per TCP cycle. Discarding too many will cause a flow to >> stall -- we see this when Web access takes forever. >> ... >> I suggest reading the excellent page: "High-Speed TCP Variants": http://kb.pert.geant2.net/PERTKB/TcpHighSpeedVariants [Charles N Wyble] Hank, This is in fact an excellent resource. Thanks for sharing it!
Re: "Does TCP Need an Overhaul?" (internetevolution, via slashdot)
On Sat, 5 Apr 2008, Kevin Day wrote: On Apr 4, 2008, at 8:51 PM, Paul Vixie wrote: What is really necessary is to detect just the flows that need to slow down, and selectively discard just one packet at the right time, but not more, per TCP cycle. Discarding too many will cause a flow to stall -- we see this when Web access takes forever. ... i wouldn't want to get in an argument with somebody who was smart and savvy enough to invent packet switching during the year i entered kindergarden, but, somebody told me once that keeping information on every flow was *not* "inexpensive." should somebody tell dr. roberts? I suggest reading the excellent page: "High-Speed TCP Variants": http://kb.pert.geant2.net/PERTKB/TcpHighSpeedVariants Enough material there to keep NANOG readers busy all weekend long. -Hank
Re: "Does TCP Need an Overhaul?" (internetevolution, via slashdot)
On Apr 5, 2008, at 9:40 AM, Kevin Day wrote: in answer to your question about SACK, it looks like they simulate a slower link speed for all TCP sessions that they guess are in the same flow-bundle. thus, all sessions in that flow-bundle see a single shared contributed bandwidth-delay product from any link served by one of their boxes. Yeah, I guess the point I was trying to make is that once you throw SACK into the equation you lose the assumption that if you drop TCP packets, TCP slows down. Before New Reno, fast-retransmit and SACK this was true and very easy to model. Now you can drop a considerable number of packets and TCP doesn't slow down very much, if at all. If you're worried about data that your clients That's only partially correct: TCP doesn't _time out_, but it still cuts its sending window in half (ergo, it cuts the rate at which it sends in half). The TCP sending rate computations are unchanged by either NewReno or SACK; the difference is that NR and SACK are much more efficient at getting back on their feet after the loss and: a) Are less likely to retransmit packets they've already sent b) Are less likely to go into a huge timeout and therefore back to slow-start You can force TCP into basically whatever sending rate you want by dropping the right packets. are downloading you're either throwing away data from the server (which is wasting bandwidth getting all the way to you) or throwing away your clients' ACKs. Lost ACKs do almost nothing to slow down TCP unless you've thrown them *all* away. You're definitely tossing useful data. One can argue that you're going to do that anyway at the bottleneck link, but I'm not sure I've had enough espresso to make that argument yet. :) I'm not saying all of this is completely useless, but it's relying a lot on the fact that the people you're trying to rate limit are going to be playing by the same rules you intended. This makes me really wish that something like ECN had taken off - any router between the two end-points can say "slow this connection down" and (if both ends are playing by the rules) they do so without wasting time on retransmits. Yup. -Dave
Re: "Does TCP Need an Overhaul?" (internetevolution, via slashdot)
On Sat, 5 Apr 2008 01:02:24 -0400 "Christopher Morrow" <[EMAIL PROTECTED]> wrote: > > On Fri, Apr 4, 2008 at 9:51 PM, Paul Vixie <[EMAIL PROTECTED]> wrote: > > > (i'd hate to think that everybody would have to buy > > roberts' (anagran's) Fast Flow Technology at every node of their > > network to make this work. that doesn't sound "inexpensive" to me. > > I suppose he could try to sell it... and people with larger networks > could see if keeping state on a few million active flows per device is > 'expensive' or 'inexpensive'. Perhaps it's less expensive than it > seems as though it would. > > Oh, will this be in linecard RAM? main-cpu-RAM? calculated on > ASIC/port or overall for the whole box/system? How about deconflicting > overlapping ip-space (darn that mpls!!!) what about asymmetric flows? > > I had thought the flow-routing thing was a dead end subject long ago? > And you can't get high speeds with Ethernet; you get too many collisions. Besides, it doesn't have any fairness properties. Clearly, you need token ring. Oh yeah, they fixed those. I have no idea if it's economically feasible or not -- technology and costs change, and just because something wasn't possible 5 years ago doesn't mean it isn't possible today. It does strike me that any such scheme would be implemented on access routers, not backbone routers, for lots of good and sufficient reasons. That alone makes it more feasible. I also note that many people are using NetFlow, which shares some of the same properties as this scheme. As for the need -- well, it does deal with the BitTorrent problem, assuming that that is indeed a problem. Bottom line: I have no idea if it makes any economic sense, but I'm not willing to rule it out without analysis. --Steve Bellovin, http://www.cs.columbia.edu/~smb
Re: "Does TCP Need an Overhaul?" (internetevolution, via slashdot)
On Apr 5, 2008, at 7:49 AM, Paul Vixie wrote: You've also got fast retransmit, New Reno, BIC/CUBIC, as well as host parameter caching to limit the affect of packet loss on recovery time. I don't doubt that someone else could do a better job than I did in this field, but I'd be really curious to know how much of an effect a intermediary router can have on a TCP flow with SACK that doesn't cause more packet loss than anyone would put up with for interactive sessions. my takeaway from the web site was that one of the ways p2p is bad is that it tends to start several parallel tcp sessions from the same client (i guess think of bittorrent where you're getting parts of the file from several folks at once). since each one has its own state machine, each will try to sense the end to end bandwidth-delay product. thus, on headroom-free links, each will get 1/Nth of that link's bandwidth, which could be (M>1)/Nth aggregate, and apparently this is unfair to the other users depending on that link. This is true. But it's not just bittorrent that does this. IE8 opens up to 6 parallel TCP sockets to a single server, Firefox can be tweaked to open an arbitrary number (and a lot of "Download Optimizers" do exactly that), etc. Unless you're keeping a lot of state on the history of what each client is doing, it's going to be hard to tell the difference between 6 IE sockets downloading cnn.com rapidly and bittorrent masquerading as HTTP. i guess i can see the point, if i squint just right. nobody wants to get blown off the channel because someone else gamed the fairness mechanisms. (on the other hand some tcp stacks are deliberately overaggressive in ways that don't require M>1 connections to get (M>1)/Nth of a link's bandwidth. on the internet, generally speaking, if someone else says fairness be damned, then fairness will be damned. Exactly. I'm nervously waiting for the first bittorrent client to have their own TCP engine built into it that plays even more unfairly. I seem to remember a paper that described where one client was sending ACKs faster than it was actually receiving the data it from several well connected servers, and ended up bringing enough traffic in to completely swamp their university's pipes. As soon as P2P authors realize they can get around caps by not playing by the rules, you'll be back to putting hard limits on each subscriber - which is where we are now. I'm not saying some fancier magic couldn't be put over top of that, but that's all depending on everyone to play by the rules to begin with. however, i'm not sure that all TCP sessions having one endpoint in common or even all those having both endpoints in common ought to share fate. one of those endpoints might be a NAT box with M>1 users behind it, for example. in answer to your question about SACK, it looks like they simulate a slower link speed for all TCP sessions that they guess are in the same flow- bundle. thus, all sessions in that flow-bundle see a single shared contributed bandwidth-delay product from any link served by one of their boxes. Yeah, I guess the point I was trying to make is that once you throw SACK into the equation you lose the assumption that if you drop TCP packets, TCP slows down. Before New Reno, fast-retransmit and SACK this was true and very easy to model. Now you can drop a considerable number of packets and TCP doesn't slow down very much, if at all. If you're worried about data that your clients are downloading you're either throwing away data from the server (which is wasting bandwidth getting all the way to you) or throwing away your clients' ACKs. Lost ACKs do almost nothing to slow down TCP unless you've thrown them *all* away. I'm not saying all of this is completely useless, but it's relying a lot on the fact that the people you're trying to rate limit are going to be playing by the same rules you intended. This makes me really wish that something like ECN had taken off - any router between the two end-points can say "slow this connection down" and (if both ends are playing by the rules) they do so without wasting time on retransmits. -- Kevin
Re: "Does TCP Need an Overhaul?" (internetevolution, via slashdot)
> You've also got fast retransmit, New Reno, BIC/CUBIC, as well as host > parameter caching to limit the affect of packet loss on recovery time. I > don't doubt that someone else could do a better job than I did in this > field, but I'd be really curious to know how much of an effect a > intermediary router can have on a TCP flow with SACK that doesn't cause more > packet loss than anyone would put up with for interactive sessions. my takeaway from the web site was that one of the ways p2p is bad is that it tends to start several parallel tcp sessions from the same client (i guess think of bittorrent where you're getting parts of the file from several folks at once). since each one has its own state machine, each will try to sense the end to end bandwidth-delay product. thus, on headroom-free links, each will get 1/Nth of that link's bandwidth, which could be (M>1)/Nth aggregate, and apparently this is unfair to the other users depending on that link. i guess i can see the point, if i squint just right. nobody wants to get blown off the channel because someone else gamed the fairness mechanisms. (on the other hand some tcp stacks are deliberately overaggressive in ways that don't require M>1 connections to get (M>1)/Nth of a link's bandwidth. on the internet, generally speaking, if someone else says fairness be damned, then fairness will be damned. however, i'm not sure that all TCP sessions having one endpoint in common or even all those having both endpoints in common ought to share fate. one of those endpoints might be a NAT box with M>1 users behind it, for example. in answer to your question about SACK, it looks like they simulate a slower link speed for all TCP sessions that they guess are in the same flow-bundle. thus, all sessions in that flow-bundle see a single shared contributed bandwidth-delay product from any link served by one of their boxes.
Re: fiber switch for gig
Just a question what is the group opinion on Dell L3 Power Connect switch's ? Best regards, Fernando Jeff McAdams wrote: Tim Durack wrote: I guess we've had good experience with ProCurve, so have stuck with them. I also like the fact that it is the same code train for the 5400 chassis and 3500 fixed-format. Less work for me when it comes to the test-upgrade cycle. We also make heavy use of sFlow monitoring (although I believe Foundry supports this too.) Anyway, it's another option. As another Procurve user (also 3500's)...I'd point out that Procurve has a lifetime warranty on their gear. -- Fernando Ribeiro Departamento de Internet Tvtel Comunicações S.A. http://www.tvtel.pt/
Re: "Does TCP Need an Overhaul?" (internetevolution, via slashdot)
Reworded: What I'm not quite sure "Fast Flow" is exactly what is it really doing that isn't being done already by the DPI vendors (eg. Cisco SCE2000 on the Cisco webpage claims to be able to track 2million unidirectional flows). Am I missing something? Aside from my horribly broken attempt at English? :-) MMC MMC Paul Vixie wrote: ... i wouldn't want to get in an argument with somebody who was smart and savvy enough to invent packet switching during the year i entered kindergarden, but, somebody told me once that keeping information on every flow was *not* "inexpensive." should somebody tell dr. roberts? (i'd hate to think that everybody would have to buy roberts' (anagran's) Fast Flow Technology at every node of their network to make this work. that doesn't sound "inexpensive" to me.
Re: "Does TCP Need an Overhaul?" (internetevolution, via slashdot)
I'm not quite sure about with this Fast Flow technology is exactly what it's really doing that isn't being done already by the DPI vendors (eg. Cisco SCE2000 on the Cisco webpage claims to be able to track 2million unidirectional flows). Am I missing something? MMC Paul Vixie wrote: ... i wouldn't want to get in an argument with somebody who was smart and savvy enough to invent packet switching during the year i entered kindergarden, but, somebody told me once that keeping information on every flow was *not* "inexpensive." should somebody tell dr. roberts? (i'd hate to think that everybody would have to buy roberts' (anagran's) Fast Flow Technology at every node of their network to make this work. that doesn't sound "inexpensive" to me.
RE: Flow Based Routing/Switching (Was: "Does TCP Need an Overhaul?" (internetevolution, via slashdot))
> > i wouldn't want to get in an argument with somebody who was smart and savvy > > enough to invent packet switching during the year i entered kindergarden, > > but, somebody told me once that keeping information on every flow was *not* > > "inexpensive." should somebody tell dr. roberts? > > Isn't the reason that "NetFlow" (or v10 which is the the IETF/Cisco > named IPFIX) exists the side-effect of having routers doing "flow based > routing" aka "keeping an entry per IP flow, thus using that entry for > every next packet to quickly select the outgoing interface instead of > having to go through all the prefixes" ? flow-cache based forwarding can work perfectly fine provided: - your flow table didn't overflow - you didn't need to invalidate large amounts of your table at once (e.g. next-hop change) this was the primary reason why Cisco went from 'fast-switch' to 'CEF' which uses a FIB. the problem back then was that when you had large amounts of invalidated flow-cache entries due to a next-hop change, typically that next-hop change was caused by something in the routing table - and then you had a problem because you wanted to use all your router CPU to recalculate the next-best paths yet you couldn't take advantage of any shortcut information, so you were dropping to a 'slow path' of forwarding. for a long long time now, Cisco platforms with netflow have primarily had netflow as an _accounting_ mechanism and generally not as the primary forwarding path. some platforms (e.g. cat6k) have retained a flow-cache that CAN be used to influence forwarding decisions, and that has been the basis for how things like NAT can be done in hardware (where per-flow state is necessary), but the primary forwarding mechanism even on that platform has been CEF in hardware since Supervisor-2 came out. no comment on the merits of the approach by Larry, anything i'd say would be through rose-coloured glasses anyway. cheers, lincoln. (work:[EMAIL PROTECTED])
Re: rack power question
A close second might be liquid cooled air tight cabinets with the air/water heat exchangers (redundant pair) at the bottom where leaks are less of an issue (drip tray, anyone? :) )... Something like what you suggest has been around for a year or two now, though using liquid CO2 as the coolant. It doesn't require particularly tight cabs. http://www.troxaitcs.co.uk/aitcs/products/ Is anyone using these over here? This is a far more significant strategy that simply using an alternative to water to carry the heat from the cabinets. The game is PHASE CHANGE, but unlike our traditional fairly complicated refrigeration system systems with oil return issues and artificiaally high head pressures simply to have a 100PSI MOPD to keep full flow through the TXV (even with low ambients outside) this is in its simplest form viewed as a PUMPED LIQUID heat pipe system, where there is no need for large pressure drops as the fluid goes around the loop. Your pump only has to cover piping loses and any elevation differences between the COLO space and the central machinery. There is NO insulation at all. The liquid being pumped out to finned coils on the back of each cabinet is at room temperature and as it grabs heat from the cabinet exhaust air (which is very efficient because you have it HOT and not needlessly undiluted with other room air) some of the liquid flashes to gas and you have a slurry that can easily be engineered to handle any size load you care to put in the rack. The more heat you add, the more gas and the less liquid you get back, but as long as there is still some liquid, the fluid stream is still at the room temperature it was at before entering the coil. It is perfectly happy trying to cool an empty cabinet and does not over cool that area, and can carry as much overload as you are prepaired to pay to have built in. At the central equipment, the liquid goes to the bottom of the receiver ready for immediate pumping again, and the gas is condensed back to liquid on cold coils in this receiver (think of a large traditional shell and tube heat exchanger that also acts as a receiver and also a slight subcooler for the liquid). The coils can be DX fed with any conventional refrigerant, or could be tied to the building's chilled water supply. Parallel tube bundles can provide redundant and isolated systems, and duplicating this whole system with alternate rows or even alternate cabinets fed from different systems lets you function even with a major failure. Read about their scenarios when a cooling door is open or even removed. The adjacent cabinets just get warmer entering air and can easily carry the load. Enough 55 degree ground water in some places might even let you work with a very big shell and tube condenser and NO conventional refrigeration system at all. If you have every single cabinet packed full, having just two systems each needing full double+ capacity would not be as good as having 3 or 4 interleaved systems, but that is simply a design decision, but one that can be partially deferred. Pipe for 4 interleaved isolated systems, and then run the ODD ones into one condensing/pumping system, and the EVEN ones into another. As cabinets fill, and as dollars become available for paranoia, add the other central units and flick a few normally padlocked preprovisioned valves and your are done. The valves stay for various backup strategies. You can accidentally leak some CO2 from one system to another and then sneak it back. There are NO parallel compressor oil return issues, just a large range between min and max acceptible charges of CO2. The big problem is that CO2 at room temperature is about 1000 PSI, so all this is welded stainless steel and flexible metal hoses. There need not be enough CO2 in any one system to present any suffocation hazard, but you DO want to be totally aware of that in the design. Unlike regular refrigerants, liguid CO2 is just dirt cheap, and you just vent it when changing a finned rear door - each has its own valves at the cabinet top main pipes.. You just go slowly so you don't cover everything or anyone with dry ice chips. Here is another site hawking those same Trox systems: http://www.modbs.co.uk/news/fullstory.php/aid/1735/The_next_generation_of_cooling__for_computer_rooms.html Over in Europe they are talking of a demo being easliy done if you already have chilled water the demo could use. A recent trade mag had a small pumped heat pipe like R134a system for INSIDE electronic systems - a miniature version of these big CO2 systems. Heat producing devices could be directly mounted to the evaporator rather than use air cooling fins or a water based system, and the condenser could be above. or below or wherever you need to put it and could function in arbitrary positions in the field. And no heat pipe wicks needed. The fully hermetic pump has a 50K hour MTBF and is in this case pumping R134a. T
Re: "Does TCP Need an Overhaul?" (internetevolution, via slashdot)
On Apr 4, 2008, at 8:51 PM, Paul Vixie wrote: What is really necessary is to detect just the flows that need to slow down, and selectively discard just one packet at the right time, but not more, per TCP cycle. Discarding too many will cause a flow to stall -- we see this when Web access takes forever. ... i wouldn't want to get in an argument with somebody who was smart and savvy enough to invent packet switching during the year i entered kindergarden, but, somebody told me once that keeping information on every flow was *not* "inexpensive." should somebody tell dr. roberts? I don't claim to understand this area more than Dr. Roberts either, but to paraphrase George Santayana: "Those who do not understand SACK are condemned to re-implement it." (or fight it) Years ago I worked on a project that was supposed to allow significant over-subscription of bandwidth to unmodified clients/servers by tracking the full state of all TCP traffic going through it. When the output interface started filling up, we'd do tricks like delaying the packets and selectively dropping packets "fairly" so that any one flow wasn't penalized too harshly unless it was monopolizing the bandwidth. To sum up many months of work that went nowhere: As long as you didn't drop more packets than SACK could handle (generally 2 packets in-flight) dropping packets is pretty ineffective at causing TCP to slow down. As long as the packets are making it there quickly, and SACK retransmits happen fast enough to keep the window full... You aren't slowing TCP down much. Of course if you're intercepting TCP packets you could disable SACK, but that strikes me as worse off than doing nothing. If you are dropping enough packets to stall SACK, you're dropping a lot of packets. With a somewhat standard 32K window and 1500 byte packets, to lose 3 non-contiguous packets inside a 32K window you're talking about 13% packet loss within one window. I would be very annoyed if I were on a connection that did this regularly. You get very little granularity when it comes to influencing a SACK flow - too little loss and SACK handles it without skipping a beat. Too much loss and you're severely affecting the connection. You've also got fast retransmit, New Reno, BIC/CUBIC, as well as host parameter caching to limit the affect of packet loss on recovery time. I don't doubt that someone else could do a better job than I did in this field, but I'd be really curious to know how much of an effect a intermediary router can have on a TCP flow with SACK that doesn't cause more packet loss than anyone would put up with for interactive sessions. The biggest thing we learned was that end user perceived speed is something completely different from flow speed. Prioritizing UDP/53 and TCP setup packets had a bigger impact than anything else we did, from a user's perspective. If either of those got delayed/dropped, pages would appear to stall while loading, and the delay between a click and visible results could greatly increase. This annoyed users far more than a slow download. Mark UDP/53 and tcpflags(syn) packets as high priority. If you wanted to get really fancy and can track TCP state, prioritize the first 2k of client->server and server->client of HTTP to allow the request and reply headers to pass uninterrupted. Those made our client happier than anything else we did, at far far less cost. -- Kevin
Re: Flow Based Routing/Switching (Was: "Does TCP Need an Overhaul?" (internetevolution, via slashdot))
On Apr 5, 2008, at 5:16 PM, Jeroen Massar wrote: The flows are in those boxes, but only for stats purposes exported with NetFlow/IPFIX/sFlow/etc. Apparently it was not as fast as they liked it to be This is essentially correct. NetFlow was originally intended as a switching mechanism, but then it became apparent that the value of the information in the cache and the ability to export it as telemetry were of more value, as there were other, more efficient methods of moving the packets around. --- Roland Dobbins <[EMAIL PROTECTED]> // +66.83.266.6344 mobile History is a great teacher, but it also lies with impunity. -- John Robb
Flow Based Routing/Switching (Was: "Does TCP Need an Overhaul?" (internetevolution, via slashdot))
Paul Vixie wrote: [..] i wouldn't want to get in an argument with somebody who was smart and savvy enough to invent packet switching during the year i entered kindergarden, but, somebody told me once that keeping information on every flow was *not* "inexpensive." should somebody tell dr. roberts? Isn't the reason that "NetFlow" (or v10 which is the the IETF/Cisco named IPFIX) exists the side-effect of having routers doing "flow based routing" aka "keeping an entry per IP flow, thus using that entry for every next packet to quickly select the outgoing interface instead of having to go through all the prefixes" ? The flows are in those boxes, but only for stats purposes exported with NetFlow/IPFIX/sFlow/etc. Apparently it was not as fast as they liked it to be and there where other issues. Thus what exactly is new here in his boxes that has not been tried and failed before? Greets, Jeroen signature.asc Description: OpenPGP digital signature
