[e2e] Can feedback be generated more fast in ECN?

[Neil Spring]

> > In 5% of SQ'd cases, the sender won't slow down.
> 
> This requires a lot of assumptions.
> 
>   It requires all of the original data from the sufficiently-large
>   cwin to get through the receiver-side congestion.

With ECN in a low congestion scenario, this would
be expected.  If we continue to talk about 8 packets,
even a 12.5% marking rate would favor marking only one,
letting all of them through.

I am not going to argue that under packet loss,
ECN provides any congestion control related benefits.
Comparing ECN and SQ when packets are being dropped seems
like a waste of time.  ECN will reduce to plain old TCP,
and it's really too late for SQ's allegedly fast congestion
response to be useful.  I am arguing that under mild
("incipient") congestion along the forward path, ECN is
robust to reasonable reverse-path loss.

>   It requires SQ to be discarded (granted).

we're talking about reliability, after all.  And I am
focusing only on the (insert reverse-path loss rate here)%
of scenarios.

>   It requires the trailing ACK to survive so that rwin on the
>   sender can be shifted without affecting cwin.

why?  any of the ACKs can cause the sender to (partially)
advance the window.  it may have to back off and slow down.
what does the sender's rwin have to do with anything?
do you assume that the receiver is too slow to read data
from the socket before sending an acknowledgement, and that
the "trailing" ack is needed to reopen the window?

>   It requires that the trailing ACK arrive within a reasonable
>   amount of time.

I don't understand how this matters.  What delays would
apply to certain acks and not others?  How would trailing
ACK delay affect whether congestion signals are delivered?
I see *nothing* special in the trailing ack - if it is
delayed or lost, this can only serve to reduce bursts
of traffic.  

> Even after all of that, it also assumes that the next burst won't trigger
> another SQ or inbound loss, and that the subsequent SQ will also be eaten
> while the trailing ACK won't, ad infinitum. We are moving from marginal
> probability into fractional.

By then, ECN would have reduced the sending rate.
SQ would not.  Eventually, enough SQ's may be generated to
overwhelm whatever loss probability exists, so I concede
that eventually (and too late) an SQ will arrive.  If this
is all that is necessary to provide "reliable" congestion
signal delivery in SQ, I think we've found our disagreement
over semantics.

> I can assure you that a sender will almost certainly slow down in the face
> of 5% bi-directional loss, even without the use of SQ or ECN.

> The "implicit" TCP mechanisms work for SQ just like they do for ECN.

So I assumed that the SQ "beating" ECN proposal would
allow SQ'd data packets to be delivered to the receiver.
Since both SQ and ECN-acks can be dropped (SQ because
you wouldn't generate ICMP for ICMP, unless you want to
prioritize SQ packets and open yourself to awful DoS
attack,  and ECN-acks because I believe they're sent
ECN-incapable) a 5% mark or quench rate on the outgoing
path would be met with a 5% drop rate on the return path.

If you do not want SQ'd packets to be delivered, then
my faith in the utility of ECN is undiminished.  If you
want SQ'd packets to be delivered, than the implicit TCP
mechanisms do NOT work for SQ.

-neil
ps. sorry about my math on the previous message, it should
have read (0.05)^4, not 1-(0.05)^4.  Thanks, Kostas.