On Sat, 21 Mar 2015, Michael Welzl wrote:
On 21. mar. 2015, at 01.03, David Lang <da...@lang.hm> wrote:
On Fri, 20 Mar 2015, Michael Welzl wrote:
On 20. mar. 2015, at 17.31, Jonathan Morton <chromati...@gmail.com> wrote:
On 20 Mar, 2015, at 16:54, Michael Welzl <mich...@ifi.uio.no> wrote:
I'd like people to understand that packet loss often also comes with delay -
for having to retransmit.
Or, turning it upside down, it’s always a win to drop packets (in the service
of signalling congestion) if the induced delay exceeds the inherent RTT.
Actually, no: as I said, the delay caused by a dropped packet can be more than
1 RTT - even much more under some circumstances. Consider this quote from the
intro of https://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01 :
You are viewing this as a question to drop a packet or not drop a packet.
The problem is that isn't the actual question.
The question is to drop a packet early and have the sender slow down, or wait
until the sender has filled the buffer to the point that all traffic
(including acks) is experiencing multi-second latency and then drop a bunch
of packets.
In theory ECN would allow for feedback to the sender to have it slow down
without any packet being dropped, but in the real world it doesn't work that
well.
I think it's about time we finally turn it on in the real world.
1. If you mark packets as congested if they have ECN and drop them if they
don't, programmers will mark everything ECN (and not slow transmission)
because doing so gives them an advantage over applications that don't mark
their packets with ECN
I heard this before but don't buy this as being a significant problem (and
haven't seen evidence thereof either). Getting more queue space and
occasionally getting a packet through that others don't isn't that much of an
advantage - it comes at the cost of latency for your own application too
unless you react to congestion.
but the router will still be working to reduce traffic, so more non-ECN flows
will get packets dropped to reduce the
loadhttp://email.chase.com/10385c493layfousub74lnvqaaaaaahg7lbwdgdvonyyaaaaa/C?V=emlwX2NvZGUBAUNVU1RfTEFTVF9OTQFMQU5HAVJFV0FSRFNfQkF
MQU5DRQExNi43MwFnX2luZGV4AQFDVVNUX0ZJUlNUX05NAURBVklEAUxBU1RfNAE1NDE3AWxfaW5kZXgBAXByb2ZpbGVfaWQBNDg0Mzk5MjEyAW1haWxpbmdfaWQBMTE
0OTI5NTU5AV9XQVZFX0lEXwE4NTY2MDAxNzQBX1BMSVNUX0lEXwExNjgwMTYwMQFVTlFfRU5STF9DRAEyMTEyMzkzOTE1AWVtYWlsX2FkX2lkAQFMU1RfU1RNVF9EQVR
FATAyLzAxLzE1AWVtYWlsX2FkZHIBZGF2aWRAbGFuZy5obQFfU0NIRF9UTV8BMjAxNTAzMjAyMTAwMDABcHJvZmlsZV9rZXkBQTE0NjQ3MjgxMTQ%3D&KwXv5L3yGN8q
uPM67mqc0Q
marking packets with ECN gives an advantage to them in mixed environments
2. If you mark packets as congested at a lower level than where you drop
them, no programmer is going to enable ECN because flows with ECN will be
prioritized below flows without ECN
Well.... longer story. Let me just say that marking where you would otherwise
drop would be fine as a starting point. You don't HAVE to mark lower than
you'd drop.
If everyone use ECN you don't have a problem, but if only some
users/applications do, there's no way to make it equal, so one or the other
is going to have an advantage, programmers will game the system to do
whatever gives them the advantage
I don't buy this at all. Game to gain what advantage? Anyway I can be more
aggressive than everyone else if I want to, by backing off less, or not
backing off at all, with or without ECN. Setting ECN-capable lets me do this
with also getting a few more packets through without dropping - but packets
get dropped at the hard queue limit anyway. So what's the big deal? What is
the major gain that can be gained over others?
for gamers, even a small gain can be major. Don't forget that there's also the
perceived advantage "If I do this, everyone else's packets will be dropped and
mine will get through, WIN!!!"
David Lang
_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat