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
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 infor
> 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 ther
> 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 selli
outstanding compilation Hank, thanks !!!
Rgds
-Jorge
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
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 m
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 c
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 pro
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
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 cur
> 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
> intermed
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
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 attemp
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
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 coola
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 se
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,
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
20 matches
Mail list logo
