NOTE: Previous message contained the right information, but with the
subject referring to the wrong year. Apologies for the noise.
The next OARC Spring Workshop will take place in Amsterdam on May 9th
and 10th, the weekend before RIPE70. OARC is requesting proposals for
presentations, with a preference for DDoS attack reports and mitigation
techniques. Reports and field stories can cover DNS-based DDoS attacks,
attacks to DNS infrastructure or side effects suffered by cache resolver
This workshop intends to build from previous strong OARC workshops,
where operational content and research is welcome. Presentations from
DNS operators are particularly welcome, as well as from DNS researchers.
All DNS-related subjects are accepted, introduction to new tools,
visualizations, DNSSEC and novel uses of the DNS. If you are an OARC
member, and have a sensitive topic you would like to present for
members-only, we will accommodate those talks too. Adopting practice
from other conferences, a timeslot for lighting talks will be available
for short presentations (5 to 10 minutes).
* 18 December 2014, Call for Presentations posted
* 8 January 2015, Open for submissions
* 12 March 2015, Deadline for submission. Please note deadline was
extended for an extra week.
* 26 March 2015, Final Program published
* 7 May 2015, Final deadline for slideset submission
Details for abstract submission will be published here:
The workshop will be organized on different tracks, depending on the
topics and the timing of each presentation. If you are interested in a
lightning talk, let us know at the time of submission.
You can contact the Programme Committee:
via <submissions(a)dns-oarc.net> if you have questions or concerns.
Sebastian Castro, for the OARC Programme Committee
OARC is also seeking sponsorship for this workshop, please contact
<sponsor(a)dns-oarc.net> if your organization is interested in becoming a
(Please note that OARC is run on a non-profit basis, and is not in a
position to reimburse expenses or time for speakers at its meetings.)
Technical Research Manager
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 495 2337
mobile: +64 21 400535
I had spoken to someone at nznog that promised to combine mrtg +
smokeping or cacti + smokeping so as to be able to get long term
latency and bandwidth numbers on one graph. cc added.
On Thu, Mar 5, 2015 at 12:38 PM, Matt Taggart <matt(a)lackof.org> wrote:
> Dave Taht writes:
>> wow. It never registered to me that users might make a value judgement
>> based on the amount of ping *loss*, rather than latency, and in looking back in time, I can
>> think of multiple people that have said things based on their
>> perception that losing pings was bad, and that sqm-scripts was "worse
>> than something else because of it."
> This thread makes me realize that my standard method of measuring latency
> over time might have issues. I use smokeping
in sqm-scripts's case, possibly, all you have been collecting is
largely worst case behavior, which I don't mind collecting as it tends
to be pretty good. :)
However, I have been unclear. In the main (modern - I don't know what
version you have) sqm code, IF you enable dscp squashing on inbound
(the default), you do end up with a single fq_codel queue, not 3, no
classification or ping prioritization. (it is the default because of
all the re-marking I have seen from comcast)
So if you are, as I am, monitoring your boxes from the outside, there
is no classification and prioritization present for ping.
do a tc -s qdisc show ifbwhatever (varies by platform) to see how many
queues you have. Example of a single queued inbound rate limiter +
fq_codel (yea! packet drop AND ecn working great!)
root@lorna-gw:~# tc -s qdisc show dev ifb4ge00
qdisc htb 1: root refcnt 2 r2q 10 default 10 direct_packets_stat 0
Sent 168443514948 bytes 334370551 pkt (dropped 0, overlimits
143273498 requeues 0)
backlog 0b 0p requeues 0
qdisc fq_codel 110: parent 1:10 limit 1001p flows 1024 quantum 300
target 5.0ms interval 100.0ms ecn
Sent 168443514948 bytes 334370551 pkt (dropped 17480, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
maxpacket 1514 drop_overlimit 0 new_flow_count 125872421 ecn_mark 1044
new_flows_len 0 old_flows_len 1
12:45:35 up 54 days, 22:33, load average: 0.05, 0.05, 0.04
dscp classification in general, is only useful from within your own
network, going outside.
> which is a really nice way of measuring and visualizing packet loss and
> variations in latency. I am using the default probe type which uses fping
> (ICMP http://www.fping.org/ ).
I LOVE smokeping and wish very much we had a way to combine it with
mrtg data to see latency AND bandwidth at the same time.
> It has been working well, I set it up for a site in advance of setting up
> SQM and then afterwards I can see the changes and determine if more tuning
> is needed. But if ICMP is having it's priority adjusted (up or down), then
> the results might not reflect the latency of other services.
> Fortunately the nice thing is that many other probe types exist
> So which probe types would be good to use for bufferbloat measurement? I
> guess the answer is "whatever is important to you", but I also suspect
> there is a set of things that ISPs are known to mess with.
> HTTP? But also maybe HTTPS in case they are doing some sort of transparent
> I suppose you could even do explicit checks for things like Netflix (but
> then it's easy to go off on a tangent of building a net neutrality
> On a somewhat related note, I was once using smokeping to measure a fiber
> link to a bandwidth provider and had it configured to ping the router IP on
> the other side of the link. In talking to one of their engineers, I learned
> that they deprioritize ICMP when talking _with_ their routers, so my
> measurement weren't valid. (I don't know if they deprioritize ICMP traffic
> going _through_ their routers)
I do strongly recomend deprioritizing ping slightly, and as I noted, I
have seen many a borken
script that actually prioritized it, which is foolish, at best.
I keep hoping multiple (many!) someones here will go have lunch with
their company's oft lonely, oft starving sysadmin(s), to ask them what
they are doing as to firewalling, QoS and traffic shaping. Most of the
ones I have talked are quite eager to show off their work, which is
unfortunately often of wildly varying quality and complexity.
I find that an offer of saki and sushi are most conducive to getting
that conversation started.
I certainly would like to see more default corporate
firewall/QoS/shaping rules than I have personally, for various
platforms. Someone's got to have some good ideas in them... and it
would be nice to know how far the bad ones, have propagated.
> Matt Taggart
Let's make wifi fast, less jittery and reliable again!
ICANN has updated the IANA IPv4 Recovered Address Space registry according to the Global Policy for Post Exhaustion IPv4 Allocation Mechanisms by the IANA. The policy states that in each IPv4 allocation period, each RIR will receive a single IPv4 allocation unit from ICANN. An IPv4 allocation period is defined as a 6-month period following 1 March or 1 September in each year.
The address space selection software can be downloaded from: https://github.com/icann/
The list of allocations can be found at: https://www.iana.org/assignments/ipv4-recovered-address-space/ipv4-recovere…
Internet Assigned Numbers Authority (IANA)
Internet Corporation for Assigned Names & Numbers
12025 Waterfront Drive, Suite 300
Los Angeles, CA 90094
Phone: +1 310 301 5800