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

[Kaleelazhicathu R R Kumar]

Ram,

On Fri, 16 Feb 2001, K. K. Ramakrishnan wrote
> 
> We have discussed this issue extensively before. One of the issues that
> has concerned me is the lack of an appropriate incentive for ECN
> compliance, with marking the CE bit in the ack. A receiver could
> ignore the CE bit in the ack with impunity because of the nature of
> cumulative acknowledgments.

Assuming scenarios like 30% congestion due to reasons like Napster 
traffic ,enabling the ECT bit for pure ACKs would  greatly
help...Here  much of the traffic is ftp with more
 amount of pure acks on the fly ..Hence in such heavy
congestion scenario, likelihood of acks getting lost is very high which
means that sometimes multiple drops of acks could occur. This multiple
drop could lead to the servers timing out and in some cases
retransmitting the duplicate data which may  aggregating congestion in
the middle. The setting of ECT bit in the pure ack could solve this
problem preventing timeouts and duplicate transmissions to a greater
extent unless there is a tail drop or the av. queue crosses the max. drop
prob. in RED.
....The setting of ECT bit would serve 2 purposes.
 1) Pure ACKs could be delivered  with minimum loss intimating reception
of data packets which would be crucial in the above mentioned case. 
 2) Probability of successful  intimation of forward congestion would be
higher. 


> 
> With data packets, if I ignore ECN, then there is the possibility
> that I  would begin to experience more packet loss, and hence
> reduced performance. If I ignore ECN indications in the ACK,
> then even if acks. are lost, the cumulative ack would provide
> me enough information.
we can ignore the CE indication in pure ACKs but it would certainly help
the server to be notified that the data has been received and it can avoid
a duplicate transmission which wouldn't  be the case now if no pure acks
are received at all in an RTT time. This would be more evident in heavy
congestion.
  ECN being a receiver initiated feedback, the reception of
ACKs whether with data or pure would be equally important for
successful completion of congestion indication as the ACK does carry
many other useful information along with forward congestion
indication which can be used to improve the TCP
performance over a congested link.




> 
> There have been proposals for reacting to congestion in the
> ack path, but we've felt that we need to understand the
> situation more thoroughly before suggesting deployment.

Setting of an ECN bit has other benefits too especially in
multiple ACK loss conditions as mentioned
above other than reacting to congestion in the ACK path. 
your opinion??

Renjish.


> 
>   K. K. Ramakrishnan
> 
> Kaleelazhicathu R R Kumar wrote:
> 
> > The RFC 2481 talks about sending a pure ack with ECT bit set to 0. Can we
> > not set the ECT bit for a pure ack as well?? This could help in avoiding
> > ack loss in the reverse direction to a greater extent. The receiver of
> > the pure ack can be modified  to behave appropriately  when a CE bit is
> > found or don't react at all.
> >
> > Renjish
>