Jonathan,
Will you be writing up this ELR idea soon? You might not realise that
your descriptions of it so far in emails have not been understandable
(to me), so a proper write up is needed. I'm not even sure what problem
it is trying to solve (don't spend time explaining by email - write it
up properly pls).
We are currently finalising an Internet draft on an identifiers for L4S
(aimed for the tsvwg, which owns ECN and Diffserv standardisation, but
I'll cross-post to aqm too). It should appear before Monday's IETF
deadline. It will be written as if it is a draft to standardise the
chosen identifier), with all the proposals and their pros and cons in an
appendix.
Inline...
On 07/08/15 08:55, Jonathan Morton wrote:
A flow-isolating AQM such as fq_codel would be able to deal with
different flows responding differently to CE.
The problem is that core and semi-core network nodes don't have the
resources to do flow isolation at line rate, or (equivalently) they
deal with too many simultaneous flows to make a meaningful flow
isolation scheme practically implementable. This, I assume, is where
the dual queue proposal comes in.
Yes, and because flow-queuing overrides the packet rate choices of
applications (breaking the end-to-end principle). In testing, fq
completely rips apart CBR and variable rate video when running alongside
long-running TCP flows, when they would otherwise work just fine in a FIFO.
I've been whingeing about this ever since fq_CoDel was first mooted. But
I didn't want to make too much noise until we had fully tested a better
alternative.
Fundamentally, dual queue needs to be able to identify the packets
belonging to each queue. DSCP is a non-starter because it doesn't, in
practice, survive end to end.
Not a complete non-starter. A valid deployment model is for ISPs to
initially deploy L4S for their own services (CDNs, premium services etc)
as local-network only. Then as more e2e ECN sources migrate to L4S (and
any attempt to use the DSCP gets bleached), each ISP could choose to
remove the DSCP rule from its L4S queues leaving only the ECN rule, so
that ECN alone could become the identifer, and it would work e2e.
At the moment we're favouring ECT(1), but I keep wavering as I find new
issues with each approach. Watch for the draft.
I'm wary of using the ECN field for the same purpose - it could work,
but promotimg CE packets from classic ECN flows could result in
spurious retransmissions due to reordering.
I'd need the experts to confirm this, but I don't think this would lead
to spurious retransmits - at least very rarely - and very rare spurious
retransmissions are not a problem.
Reason: If a classic CE-marked packet arrives earlier than the rest of
the flow around it, TCP will see one dupack. Then subsequent (non-CE)
packets will continue to advance the cumulative ACK number closing the
gap towards the one packet up ahead, so there will be no further
dupacks. With SACK, it will report the gap on the SACK of the CE packet,
then again, subsequent packets will close the gap, so no ill effects - I
believe.
An odd packet delivered early might confuse the smart mechanisms (in
e.g. Linux) for characterising the level of persistent re-ordering,
which are intended to prevent spurious retransmits. But a good algo
should be able to ignore outliers.
3 classic CEs in a row would cause a spurious retransmit. But the
probability of that from a good AQM should be tiny.
Also, reordered CE packets would be very rare in the first place because:
i) it is quite unusual to experience more than one bottleneck queue on a
path;
ii) even then, reordering would only occur if there was simultaneous
mixing of classic and L4S traffic, which would be more unlikely in an
access link, which is where most bottlenecks are located.
Simply using the presence of ECN capability is also a bad idea,
because Apple's imminent deployment of classic ECN to millions of end
hosts will break that assumption.
Agreed. Altho the deployment seemed to have happened, I looked at
packets emitted from my iPhone after it autoinstalled the public release
of iOS 9.0.2, a few days ago, and SYNs did not attempt to negotiate ECN.
I've tried to find out what's (not) happening from Apple, but...?
A more robust deployment option would be to use a new transport
protocol ID. Then it wouldn't be TCP any more, and you can throw away
some cruft while you're at it. I'll leave the problems with that idea
to your fertile imaginations.
Nah. Lots of reasons why the protocol ID is not useful for this. Pasting
from our draft to be...
* A new protocol ID would need to be paired with the old one for each
transport (TCP, SCTP, UDP, etc.);
* In IPv6, there can be a sequence of Next Header fields, and it would
not be obvious which one would be expected to identify a network service
like L4S;
* A new protocol ID would rarely provide an end-to-end service, because
It is well-known that new protocol IDs are often blocked by numerous
types of middlebox;
* The approach is not a solution for AQMs below the IP layer;
The middlebox bullet is the killer (which is why DCCP, SCTP etc still
don't work e2e).
As a gentle reminder, ELR is designed to solve the same problem while
avoiding these deployment problems. It does "burn" ECT(1), but for a
good cause and - crucially - doesn't require the network to be aware
of it before endpoints can safely turn it on.
ELR sounds similar to previously published stuff (VCP maybe?). But until
you write it up, we can't tell for sure.
Bob
- Jonathan Morton
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
--
________________________________________________________________
Bob Briscoe http://bobbriscoe.net/
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
