Good point about separating concerns. I would suggest that home router to POP
encryption would satisfy the first. End to end encryption can be done at the
endpoints on, as it should be.
The home router to POP link need not be tappable for the NSA for it to spy. It
is not end to end.
Sent from
Thanks for this. I hadn't seen it yet.
On Friday, December 15, 2017 2:32pm, "tapper" said:
> Motherboard & VICE Are Building a Community Internet Network
> https://motherboard.vice.com/en_us/article/j5djd7/motherboard-and-vice-are-building-a-community-internet-network-to-protect-net-neutrali
The disaster in the FCC's move to reverse the Open Internet Order will probably
continue.
As some of you may know, but most probably don't, I have a somewhat nuanced
view of the best way to preserve what is called network neutrality. That's
because I have a precise definition of what the Inte
Just to be clear, I have built and operated a whole range of network platforms,
as well as diagnosing problems and planning deployments of systems that include
digital packet delivery in real contexts where cost and performance matter, for
nearly 40 years now. So this isn't only some kind of ra
Luca's point tends to be correct - variable latency destroys the stability of
flow control loops, which destroys throughput, even when there is sufficient
capacity to handle the load.
This is an indirect result of Little's Lemma (which is strictly true only for
Poisson arrival, but almost any
I suggest we stop talking about throughput, which has been the mistaken idea
about networking for 30-40 years.
Almost all networking ends up being about end-to-end response time in a
multiplexed system.
Or put another way: "It's the Latency, Stupid".
I get (and have come to expect) 27 msec
Sooner or later it dawns on all security professionals that the idea of a
"provably secure system" is a pipedream. Same with systems designers working on
fault tolerance who are tasked with making their systems "NonStop" as the
Tandem claim used to go.
What we see here in most of the examples
No disagreement here. I saw a wonderful discussion recently by a researcher at
Mentor Graphics about 2 things: VLSI design hacking and low level interconnect
hacking. Things we call "hardware" and just assume are designed securely.
They are not. The hardware designers at the chip and boa
It doesn't jump to mind, but a radio carrying bits near the edge probably won't
be used near capacity most of the 24 hours it is operating. Just as Iridium was
designed to quiesce most of its electronics on the dark side of the earth,
extending its battery life, you can probably assume that a ra
"Deep discharge" batteries work in LEO satellites for such applications. But
they are extraordinarily expensive, because the designs are specialized, and
that use case doesn't have the 2-3 day solar outage problem.
You are not going to put a good enough system for an AP up in a tree. Maybe on
a
https://arxiv.org/abs/1701.02528
Interesting approach. Nice analysis.
Needs to be in OpenWRT?
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel
My understanding is that it is already settled case law that contributed code
to a GPL licensed projects implicitly grants a perpetual, royalty free license
to use any applicable patent the author uses in the code.
Of course there is no case law regarding patent s in other licenses, in
particul
The language used in the article seems confused. However, since firmware
sometimes means software (the OS kernel, for example) and this is "lag under
load", it's barely possible that this is bufferbloat of a sort, it seems. Would
we be surprised?
200 ms. can also be due to interrupt mishandling
Reading between the lines on the datasheet, the "packet processor" doesn't look
to be anything fancy or problematic. It contains:
DMA - meaning that it will transfer into and out of the Tx and Rx rings in RAM
automatically. Every NIC does DMA at the packet level.
PTP (IEEE1588) essentially thi
On Wednesday, September 21, 2016 2:00pm, "Mikael Abrahamsson"
said:
> Yes, I guess people who have been staring at traffic graphs and Netflow
> collector system output for 10-15 years have no insight into what and how
> much traffic is going where.
That's exactly what I am saying.
__
Don't want to dwell on this, but Sandvine is not an unbiased source. And it is
apparently the *only* source - and 50% is a LOT. Even Trump and Clinton don't
have 50% of the electorate each. :-)
Does Sandvine have the resources to examine a true sample of all Internet
traffic?
Maybe the NSA d
On Wednesday, September 21, 2016 3:32am, "Alan Jenkins"
said:
> On 20/09/16 21:27, dpr...@reed.com wrote:
> I don't think the source is hard to identify. It's Sandvine press
> releases. That's what the periodic stories on Ars Technica are always
> derived from.
>
> https://www.sandvine.com/pr
bittorrent is a kind of "FTP" rather than semi-isochornous (i.e. rate-bounded)
"TV" in my personal classification. As I'm sure you know, the two are quite
different in their effects on congestion and their handling of congestion.
The idea that bittorrent dominated the Internet traffic volume at
I constantly see the claim that >50% of transmitted data on the Internet are
streaming TV. However, the source seems to be as hard to nail down as the
original claim that >50% of Internet traffic was pirated music being sent over
bittorrent.
You recently repeated that statistic as if it were a
The assumption that each flow on a path has a minimum, stable RTT fails in
wireless and multi path networks.
However, it's worth remembering two things: buffering above a certain level is
never an improvement, and flows through any shared router come and go quite
frequently on the real Inter
Maybe we all need to buy some Sandvine devices for our homes that detect IW10
and forge TCP RSTs? Or maybe Ellacoya will develop one for consumers?
That's what Comcast did when bufferbloat was killing their gear on upload, as
I'm sure we all remember. Except the FCC is not going to ask me to t
It's a terrible outcome. However, there is literally no significant support
for the alternative, either from a policy basis or from entrepreneurial folks.
N-O-N-E.
I am biased towards the entrepreneurial side, but have been fighting this on
the policy side as well in one form or another since
Without custom silicon, doing what I was talking about would involve non
standard MAC power management, which would require all devices to agree.
David Lang's explanation was the essence of what I meant. the transmission from
access point on multiple channels is just digital addition if the DACs
On Thursday, June 23, 2016 4:52pm, "David Lang" said:
> On Thu, 23 Jun 2016, dpr...@reed.com wrote:
>
>> The actual issues of transmitting on multiple channels at the same time are
>> quite minor if you do the work in the digital domain (pre-DAC). You just
>> need
>> a higher sampling rate
The actual issues of transmitting on multiple channels at the same time are
quite minor if you do the work in the digital domain (pre-DAC). You just need
a higher sampling rate in the DAC and add the two signals together (and use a
wideband filter that covers all the channels). No RF problem.
Just today I found out that a datacenter my company's engineering group is
expanding into is putting us on Arista 7050's. And our very preliminary tests
of our systems there is showiung what seems to be a latency problem under load.
I can't get in the way of the deployment process, but it's
i
Even better, it would be fun to get access to an Arista switch and some high
performance TCP sources and sinks, and demonstrate extreme bufferbloat compared
to a small-buffer switch. Just a demo, not a simulation full of assumptions
and guesses.
RRUL, basically.
On Monday, June 6, 2016 1
So did anyone write a response debunking their paper? Their NS-2 simulation
is most likely the erroneous part of their analysis - the white paper would not
pass a review by qualified referees because there is no way to check their
results and some of what they say beggars belief.
Bechtolshe
Discovery is a special case, that is not quite multicast. Discovery is
"noticing". A node wishing to be discovered must be noticed by one (or maybe
more) already existent stations in a group (groups are noticed by any member
being noticed by a member of another group).
So you don't need any fa
Interesting stuff. A deeper problem with WiFi-type protocols is that the very
idea of "multicast" on the PHY level (air interface) is flawed, based on a
model of propagation that assumes that every station can be easily addressed
simultaneously, at the same bitrate, etc. Multicast is seductive
There are many processor architectures that have different instruction memories
for different functional units.
SoCs often have multiple functional units on the same die. For radios that
allows for a pipeline. You can limit what an EPROM will accept with a crypto
signature.
This is common stu
Well, the answer is basically no on there being a current chip that is only
concerned with the PHY layer. Because chip count is a crucial part of system
cost, years ago it became the practice to put the PHY and MAC, and now the
protocol processing too, on the same mixed-signal chip. For example
As a software guy who can solder SMT chips and design PCBs, and a licensed
amateur radio operator, let me add a couple observations.
The FCCs concern is not to lock up all software on routers. All they call for
is that at certification time and in users hands, radio emissions are
restricted t
Regarding OpenWRT, one should note that the major tech industry funded
think-tank in DC (ITIF) generally is unfriendly to the FCC getting involved in
security and privacy. Heres a report they just issued:
https://itif.org/publications/2016/03/01/broadband-privacy-folly-sector-specific-rules
The
My Jetway NU93-2930 board is a NUC with dual Ethernet. It's a bare board, but
I made my own case quickly enough out of acrylic sheet using my bandsaw and
glue. Works fine. Takes a wall wart power supply as long as it delivers
between 12 V and 36 V.
I recommend it highly. Jetway probably sell
I have a Banana Pi, but I can't imagine why it would be useful as a router.
Why would Comcast even bother? A Raspberry Pi 3 would be better, and far more
available. (though I think the slow Ethernet port and low end WiFi on the
Raspberry Pi 3 would make it sort of marginal, it's certainly quite
I'm giving a talk in a couple months at a very high level, about "what's at
stake" as we move into the era of "5G" (for lack of a better word, this is what
the media all think is happening, and what has the ear of the FCC).
I'd love to have a list of brands and models that have "gone dark" to se
There's a paper from Cambridge University that focuses on evaluating Raft. In
particular they have some key findings about performance tuning, plus
discovering some potential livelocks.
I'm interested in Consul on a planet-wide scale - not sure it scales
effectively but if it or something like
I'm trying to imagine what its intended market is. Open factory/warehouse
floor networking? The atmospheric absorbtion of that band is a problem, since
oxygen's absorption peak is 60 GHz. The ability to use multipath
constructively due to the number of antennas (BLAST style MIMO) may help.
It's a start. (I'm optimistic that there is room to move the ball farther and
that the FCC folks are willing to listen, though they didn't directly address
concerns about the security closed, buggy quality of the factory software as
being important and in the public interest).
On Thursday, No
The $1K prototype looks a little different (more antennae, for sure, in the
picture). What driver, what chip does the wifi? How open is the hardware
design? (binary blobs?) Can one improve aspects of the MAC protocol in open
source?
Definitely interesting. I might be convinced to go for the pr
This is good. Regarding my concern about asking for mandated FCC-centered
control - we need less of that. It establishes a bad precedent for the means of
"protecting the airwaves". (or reinforces a precedent that must be changed
soon - of establishing de-facto, anti-innovation monopolies that
David - I find it interesting that you think I am an idiot. I design waveforms
for radios, and am, among other things, a fully trained electrical engineer
with deep understanding of information theory, EM waves, propagation, etc. as
well as an Amateur Radio builder focused on building experime
On Friday, August 7, 2015 4:03pm, "David Lang" said:
>
> Wifi is the only place I know of where the transmit bit rate is going to vary
> depending on the next hop address.
This is an interesting core issue. The question is whether additional queueing
helps or hurts this, and whether the M
On Monday, August 3, 2015 8:13pm, "David Lang" said:
>
> That requires central coordination of the stations. Something we don't have in
> wifi. Wifi lives and dies with 'listen for a gap, try transmitting, and if you
> collide, backoff a random period'
Central coordination is not the only for
I design and build physical layer radio hardware (using SDR reception and
transmission in the 5 GHz and 10 GHz Amateur radio bands).
Fairness is easy in a MAC. 1 usec. is 1,000 linear feet. If the next station
knows when its turn is, it can start transmitting within a couple of
microseconds
It's not infeasible to make queues shorter. In any case, the throughput of a
link does not increase above the point where there is always one packet ready
to go by the time the currently outgoing packet is completed. It physically
cannot do better than that.
If hardware designers can't creat
Hardware people tend to think about queues way too much in general. Queues
should be almost never occupied. That causes the highest throughput possible.
And getting there is simple: push queueing back to the source.
The average queue length into a shared medium should be as close to zero as
[ https://community.linksys.com/t5/Wireless-Routers/WRT1900AC-V2/td-p/940588 ](
https://community.linksys.com/t5/Wireless-Routers/WRT1900AC-V2/td-p/940588 )
Shows a v2 with 512M of memory, actually purchased. I would think that the 512
is definitely useful.
On Tuesday, July 7, 2015 2:09am
Having not bought a 1200ac yet, I was wondering if I should splurge for the
1900ac v2 (which has lots of memory unlike the 1900ac v1).
Any thoughts on the compatibility of this with the 1200ac?
Current plans are to deploy Supermicro Mini ITX A1SRI-2558F-O Quad Core
(Rangely) as my externally
Wonderful!
On Wednesday, July 1, 2015 9:46pm, "Jim Reisert AD1C"
said:
> Model: NETGEAR WNDR3800
> Firmware Version: OpenWrt Chaos Calmer r46069 / LuCI Master
> (git-15.168.50780-bae48b6)
>
> Comcast cable modem, 60 Mbps down/6 Mbps up (nominal)
>
> Motorola SB6141
> Hardware Version: 7.0
Mikael, very very helpful, thanks.
I now understand what you are trying to prove/test in your experiments, but
there is definitely a need for cake when the dominant use is hi-bitrate WiFi
(AC1900) talking to one or more 1 GigE wired paths. And hi bitrate WiFi itself
has significantly variabl
What happens if the SoC ports aren't saturated, but the link is GigE? That is,
suppose this is an access link to a GigE home or office LAN with wired servers?
On Tuesday, June 30, 2015 9:58am, "Mikael Abrahamsson" said:
> On Mon, 29 Jun 2015, dpr...@reed.com wrote:
>
> > I would love to t
I would love to try out cake in my environment. However, as a non-combatant,
it would be nice to have an instruction sheet on how to set the latest version
up, and what hardware it works best on (WRT1200AC?). Obviously this is a work
in progress, so that will change, but it would be nice to h
I'm curious as to why one would need low priority class if you were using
fq_codel? Are the LEDBAT flows indistinguishable? Is there no congestion
signalling (no drops, no ECN)? The main reason I ask is that end-to-end flows
should share capacity well enough without magical and rarely impleme
What's your definition of 802.11 performing well? Just curious. Maximizing
throughput at all costs or maintaing minimal latency for multiple users sharing
an access point?
Of course, if all you are doing is trying to do point-to-point outdoor links
using 802.11 gear, the issue is different -
Tools, tools, tools. Make it trivially easy to capture packets in the home
(don't require cerowrt, for obvious reasons). For example, an iPhone app that
does a tcpdump and sends it to us would be fantastic to diagnose "make wifi
fast" issues and also bufferbloat issues. Give feedback that is
DOn't want to get entangled in the political debate, but just a thought:
If you track what MAC addrs use what upstream capacity, you could have data on
which to judge who is pushing your usage over any caps you happen to have.
Having some data (not general fears or propaganda generated by those
I do think engineers operating networks get it, and that Comcast's engineers
really get it, as I clarified in my followup note.
The issue is indeed prioritization of investment, engineering resources and
management attention. The teams at Comcast in the engineering side have been
the leaders in
I'll look up the quote, when I get home from California, in my email archives.
It may have been private email from Richard Woundy (an engineering SVP at
Comcast who is the person who drove the CableLabs effort forward, working with
Jim Gettys - doing the in-house experiments...). To be clear, I
How many years has it been since Comcast said they were going to fix
bufferbloat in their network within a year?
And LTE operators haven't even started.
THat's a sign that the two dominant sectors of "Internet Access" business are
refusing to support quality Internet service. (the old saying ab
I agree wholeheartedly with your point, David.
One other clarifying point (I'm not trying to be pedantic, here, but it may
sound that way):
Reliability is not the same as Availability. The two are quite different.
Bufferbloat is pretty much an "availability" issue, not a reliability issue.
On Thursday, March 12, 2015 11:31am, "Richard Smith" said:
> On 03/10/2015 05:12 PM, Dave Taht wrote:
>
>>>
>>> This year I deployed 53 APs. I'll make an updated map showing where they
>>> were deployed.
>>
>> So far as I know all the APs were fq-codeled, but the firewall/gw was
>> not.
>
> How
+1
On Wednesday, March 4, 2015 3:19pm, "Dave Taht" said:
> As you can see over the last month I have been laughing in despair
> about the futility we seem to face in getting solutions for
> bufferbloat "out there", ever since the streamboost and gogo-in-flight
> data came in.
>
> So it occurs
It's a heavy burden to place on ICMP ping to say that it should tell you about
all aspects of its path through all the networks between source and destination.
On the other hand, I'll suggest that Fred's point - treat ICMP Ping like any
other IP datagram with the same header options is the essen
On my own web server (running nginx) I provide an HTTP 1.1 accessible
statistics service. It returns a single JSON structure with the underlying
packet statistics for the server and the current connection. Since this packet
is inserted into the HTTP 1.1 stream upon request, it provides both the
bravo!
On Sunday, March 1, 2015 6:22pm, "Dave Taht" said:
> There's nothing new here, but it was a nice rant to get out of my system:
>
> http://permalink.gmane.org/gmane.org.operators.nanog/128201
>
> Of late, I have been taking a page from Linus Torvalds' playbook, in
> realizing that "on
Dave - I understand the rationale, but the real issue here is with the
printers, etc.
Their security model is completely inappropriate - even WITHIN a home
network... depending on peripheral protection doesn't work anywhere very well.
It's so easy to break into someone's home net... either by
+1 for this idea. It really worked for Anand's and Tom's - their reviews
caught fire and got followed so much that they could become profitable
businesses from the ads.
Craigslist style business model, funding both reviewing and CeroWRT promotion
activities would be the logical thing. And I
Leaving stuff in a buffer in hopes that more will arrive is a terrible idea,
proven over and over.
However, if you already have a packet waiting to go out, combining packets
after that with each other does create some benefit at no cost (reducing
negotiation time). Coupled with something lik
On Sunday, February 1, 2015 11:21pm, "Avery Pennarun"
said:
> On Sun, Feb 1, 2015 at 9:43 AM, wrote:
> > Just to clarify, managing queueing in a single access point WiFi network is
> > only a small part of the problem of fixing the rapidly degrading performance
> > of WiFi based systems.
>
Just to clarify, managing queueing in a single access point WiFi network is
only a small part of the problem of fixing the rapidly degrading performance of
WiFi based systems. Similarly, mesh routing is only a small part of the
problem with the scalability of cooperative meshes based on the Wi
I think we need to create an Internet focused 802.11 working group that would
be to the "OS wireless designers and IEEE 802.11 standards groups" as the
WHATML group was to W3C.
W3C was clueless about the real world at the point WHATML was created. And
WHATML was a "revenge of the real" again
And having every /48 MAC address in your entterprise tracked is cheaper?
On Sunday, January 25, 2015 11:44pm, "David Lang" said:
> On Sun, 25 Jan 2015, valdis.kletni...@vt.edu wrote:
>
> > On Sun, 25 Jan 2015 18:09:59 -0800, David Lang said:
> >> The difference is that the switches and thei
Well, we all may want to agree to disagree. I don't buy the argument that hash
tables are slow compared to the TCAMs - and even if cache misses happened, a
hash table is still o(1) - you look at exactly one memory address on the
average in a hash table - that's the point of it. The constant f
Looking up an address in a routing table is o(1) if the routing table is a hash
table. That's much more efficient than a TCAM. My simple example just
requires a delete/insert at each node's route lookup table.
My point was about collections of WLAN's bridged together. Look at what
happens
If you are using Ethernet bridging, your Ethernet switches are doing exactly
this at the Ethernet layer... they have large tables of MAC addresses that are
known throughout the network, and for each MAC address in the Enterprise, they
have the next hop destination.
So IP routing tables, one I
Disagree. See below.
On Saturday, January 24, 2015 11:35pm, "David Lang" said:
> On Sat, 24 Jan 2015, dpr...@reed.com wrote:
> > A side comment, meant to discourage continuing to bridge rather than route.
> >
> > There's no reason that the AP's cannot have different IP addresses, but a
> > c
Yeah. Someone should send them to my blog post.
On Thursday, January 22, 2015 11:16pm, "Dave Taht" said:
[
http://mobile.nytimes.com/2015/01/22/style/the-sorry-state-of-in-flight-wi-fi.html?_r=2&referrer=
](
http://mobile.nytimes.com/2015/01/22/style/the-sorry-state-of-in-flight-wi-fi.ht
On Thursday, January 22, 2015 1:19pm, "Richard Smith"
said:
> On 01/22/2015 04:18 AM, David Lang wrote:
>
> >> Recently, we picked up the 11th floor as well and moved many people up
> >> there. I got a 3rd AP (another TP-Link AC1750) and set that one up on
> >> a free channel with a differen
[ GoGo does not need to run “Man in the Middle Attacks” on YouTube ](
http://www.reed.com/blog-dpr/?p=174 )___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel
Typo below - dry air attenuation is 0.0075 dB/kM from the chart. My leading "1"
was a mistake - so the water vapor adds 0.002/0.0075 = 27% to the very small
attenuation caused by air, at this frequency.
On Monday, December 22, 2014 9:16pm, dpr...@reed.com said:
Hi Sebastian -
So reading
Hi Sebastian -
So reading this chart, which is consistent with my reference materials: At 6
GHz, I see additional attenuation of water vapor being -0.002 db/kM, additional
to the dry air attenuation of 10.0075 dB/kM already due to the atmosphere, at
5.8 GHz.
So at 5 kM (>1 mile in English
Awesome start on the issue, in your note, Dave. Tor needs to change for
several reasons - not that it isn't great, but with IPv6 and other things
coming on line, plus the understanding of fq_codel's rationale, plus ... - the
world can do much better. Same with VPNs.
I hope we can set our si
The IETF used to require rough consensus and *working code*. The latter seems
to be out of fashion - especially with a zillion code points for which no
working code has been produced, and worse yet, no real world testing has
demonstrated any value whatsoever.
It's also true that almost no ac
In other words, rather than share the capacity of the link "fairly" among flows
(as TCP would if you eliminated excess buffer-bloat), you want to impose
control on an endpoint from the middle?
This seems counterproductive... what happens when the IP address changes, new
services arise, and mo
I just read the first page of the paper so far, but it sounds like it is
heading in a good direction.
It would be interesting to apply also to home access-point/switches, especially
since they are now pushing 1 Gb/sec over the air.
I will put it on my very interesting stack.
On Wednesday
The best approach to dealing with "locking overhead" is to stop thinking that
if locks are good, more locking (finer grained locking) is better. OS
designers (and Linux designers in particular) are still putting in way too much
locking. I deal with this in my day job (we support systems with
Wideband is far better for scaling than narrowband, though. This may seem
counterintuitive, but narrowband systems are extremely inefficient. They
appeal to 0/1 thinking intuitively, but in actual fact the wider the bandwidth
the more sharing and the more scaling is possible (and not be "balk
This is not completely crazy. A couple of grad students and I demonstrated
this type of thing with USRP's in my lab at MIT. The problem you, David Lang,
refer to is basically the key thing to deal with, but the physics and
information theory issues can be dealt with.
There's significant work
The speedof.me API probably can be used directly as the measurement of download
and upload - you can create a competing download or upload in Javascript using
a WebWorker talking to another server that supports the websocket API to force
buffer overflow. (sort of poor man's RRUL).
The speedo
Among friends of mine, we can publicize this widely. But those friends
probably would like to see how the measurement would work.
On Thursday, September 11, 2014 8:13pm, "Rich Brown"
said:
> ___
> Cerowrt-devel mailing list
> Cerowrt-devel@lists
I will sign. It would be better if we had an actual demonstration of how to
implement a speedtest improvement.
On Thursday, September 11, 2014 12:03pm, "Dave Taht" said:
> The theme of networks being "engineered for speedtest" has been a
> common thread in nearly every conversation I've
I'm confused
SFP is not SFP+. SFP carries at most 4.25 Gb/sec. SFP+ works at >10 Gb/sec.
So, it's not clear that the MikroTik is very useful in a 10 Gig world. It's
not immediately clear but VERY likely, that this is an "edge switch" that is
intended for collapsing the GigE copper
I agree with you if you have to install Cat6a and Cat7 structured wiring in a
building! What a nightmare trying to find contractors who can meet spec on
junction boxes, etc. and do the right testing. Every connector on the path is
problematic.
But for "casual" home networking use or research
I have been happy with the PicoPSU power supplies which are tiny ATX PSU's that
go up to 160 W.
They take 12V input, which can be supplied by an external brick or a small 12V
power supply of the sort used to supply power to lighting circuits (I use a
Meanwell NES-350-12 to power 3 boards with i
Yes.
On Friday, August 22, 2014 11:12am, "William Katsak" said:
On the FWMB-7950? Are you referring to the bypass switch?
-Bill
On Aug 22, 2014, at 10:19 AM, David P. Reed <[ dpr...@reed.com ](
mailto:dpr...@reed.com )> wrote:
You missed the on board switch which is a major differentia
I just read Vint Cerf's latest column in IEEE Internet Computing (October
2014), paper edition that arrived in the mail. Entitled "Bufferbloat and other
Internet challenges", it highlights Jim Gettys, Dave Taht, Eric Dumazet,
Codel/FQ_code, the CeroWRT/OpenWRT team, etc. pointing out that
"T
[
http://www.habeyusa.com/products/fwmb-7950-rangeley-network-communication-board/
](
http://www.habeyusa.com/products/fwmb-7950-rangeley-network-communication-board/
) looks intriguing.
Probably a bit pricey, but has lots of advantages. There's another smaller one
that might do:
[ http:
I think what is being discussed is "how to measure the quality of one
endpoint's experience of the entire Internet over all time or over a specific
interval of time".
Yet the systems that are built on top of the Internet transport do not have any
kind of uniform dependence on the underlying t
1 - 100 of 209 matches
Mail list logo
