Hi Jerry,
On Aug 23, 2014, at 20:16 , Jerry Jongerius <jer...@duckware.com> wrote:
> Request for comments on: www.duckware.com/darkaqm
>
> The bottom line: How do you know which AQM device in a network intentionally
> drops a packet, without cooperation from AQM?
>
> Or is this in AQM somewhere and I just missed it?
I am sure you will get more expert responses later, but let me try to comment.
Paragraph 1:
I think you hit the nail on the head with your observation:
The average user can not figure out what AQM device intentionally dropped
packets
Only, I might add, this does not depend on AQM, the user can not figure out
where packets where dropped in the case that not all involved network hops are
under said user’s control ;) So move on, nothing to see here ;)
Paragraph 2:
There is no guarantee that any network equipment responds to ICMP requests at
all (for example my DSLAM does not). What about pinging a host further away and
look at that hosts RTT development over time? (Minor clarification: its the
load dependent increase of ping RTT to the CMTS that would be diagnostic of a
queue, not the RTT per se). No increase of ICMP RTT could also mean there is no
AQM involved ;)
I used to think along similar lines, but reading
https://www.nanog.org/meetings/nanog47/presentations/Sunday/RAS_Traceroute_N47_Sun.pdf
made me realize that my assumptions about ping and trace route were not really
backed up by reality. Notably traceroute will not necessarily show the real
data's path and latencies or drop probability.
Paragraph 3
What is the advertised bandwidth of your link? To my naive eye this looks a bit
like power boosting (the cable company allowing you higher than advertised
bandwidth for a short time that is later reduced to the advertised speed). Your
plot needs a better legend, BTW, what is the blue line showing? When you say
that neither ping nor trace route showed anything, I assumed that you measured
concurrently to your download. It would be really great if you could
netperf-wrapper to get comparable data (see the link on
http://www.bufferbloat.net/projects/cerowrt/wiki/Quick_Test_for_Bufferbloat )
There the latency is not only assessed by ICMP echo requests but also by UDP
packets, and it is very unlikely that your ISP can special case these in any
tricky way, short of giving priority to sparse flows (which is pretty much what
you would like your ISP to do in the first place ;) )
Here is where I reveal that I am just a layman, but you complain about
the loss of one packet, but how do you assume does a (TCP) settle on its
transfer speed? Exactly it keeps increasing until it looses a packet, then
reduces its speed to 50% or so and slowly ramps up again until the next packet
loss. So unless your test data is not TCP I see no way to avoid packet loss
(and no reason why it is harmful). Now if my power boost intuition should prove
right I can explain the massive drop quite well, TCP had ramped up to above the
long-term stable and suffers several packet losses in a short time, basically
resetting it to 0 or so, therefore the new ramping to 40Mbps looks pretty
similar to the initial ramping to 110Mbps...
Paragraph 4:
I guess, ECN, explicit congestion notification is the best you can expect, or
routers will initially set a mark on a packet to notify the TCP endpoints that
they need to throttle the speed unless that want to risk packet loss. But not
all routers are configured to use it (plus you need to configure your endpoints
correctly, see: http://www.bufferbloat.net/projects/cerowrt/wiki/Enable_ECN ).
But this will not tell you where along the path congestion occurred, only that
it occurred (and if push comes to shove your packets still get dropped.)
Also, I believe, a congested router is going to drop packets to be able
to “survive” the current load, it is not going to send additional packets to
inform you that it is overloaded...
Best Regards
Sebastian
>
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
