Subject: [Tsvwg] A couple of questions on ECN

From: Fernando Gont <[email-masked]>
Date: Mon, 15 Jan 2007 05:14:14 -0300

Folks,

I have a couple of questions on RFC 3168, on which maybe you can shed 
some light.

On page 18 of RFC 3168 says:
"After the source TCP reduces its congestion window in response to a
CE packet, incoming acknowledgments that continue to arrive can
"clock out" outgoing packets as allowed by the reduced congestion
window. If the congestion window consists of only one MSS (maximum
segment size), and the sending TCP receives an ECN-Echo ACK packet,
then the sending TCP should in principle still reduce its congestion
window in half. However, the value of the congestion window is
bounded below by a value of one MSS. If the sending TCP were to
continue to send, using a congestion window of 1 MSS, this results in
the transmission of one packet per round-trip time. It is necessary
to still reduce the sending rate of the TCP sender even further, on
receipt of an ECN-Echo packet when the congestion window is one. We
use the retransmit timer as a means of reducing the rate further in
this circumstance. Therefore, the sending TCP MUST reset the
retransmit timer on receiving the ECN-Echo packet when the congestion
window is one. The sending TCP will then be able to send a new
packet only when the retransmit timer expires."

Question:
What if, when cwnd=1, more than one ACK bit with the ECE bit set is 
received? Should there be a RTO backoff, or should the RTO be simply 
repeateadly reset?

On page 36 RFC3168 says:
If we assume that the first action taken at any "penalty box" for an 
ECN capable
flow will be to drop packets instead of marking them, then
there is no way that an adversary that subverts ECN-based end-to-end
congestion control can cause a flow to be characterized as being
non-cooperative and placed into a more severe action within the
"penalty box".

Comment: I'm probably misunderstanding this paragraph. But how about 
this. An attacker forges a number of TCP segments which transit the 
"penalty box". The penalty box first switches from marking to 
dropping, but the attacker continues sending forged segments, at a 
steady rate. If there's a more severe policy at the "penalty box" for 
flows that still do not respond to end-to-end congestion control 
after switching from marking to dropping, then the attacker could 
probably trigger that "more severe policy" this way. I guess the 
penalty box will never implement a policy such as "reset 
non-responding connections", though (?).

Thanks!

Kindest regards,

--
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1