Subject: [Tsvwg] Re: RFC 3465 : ABC : ACK'd Segments Just Smaller than SMSS

From: erblichs <[email-masked]>
Date: Mon, 17 Dec 2007 11:25:51 -0800 (GMT-08:00)

-----Original Message-----
>From: Mark Allman <[email-masked]>
>Sent: Dec 14, 2007 7:54 PM
>To: erblichs <[email-masked]>
>Cc: [email-masked]
>Subject: Re: RFC 3465 : ABC : ACK'd Segments Just Smaller than SMSS 
>
>
>>       I think I am looking into the case where the ACK is just
>>       slightly smaller than SMSS where ABC is utilized and cwnd is not
>>       growing. This is not an attack. At what point, percentage wise,
>>       should a partial segment be considered large enough to allow
>>       cwnd to increase, without exposing one to the "ACK Division"
>>       attack?
>
>I don't follow this.  ABC does increase cwnd.  If an implementation is
>using ABC and cwnd is not increasing then there is a bug, I think.  
>
>Just to be clear, consider the case where we start cwnd at SMSS bytes,
>packets of size SMSS-5 bytes and use an initial window of just one
>packet (to keep things easy).  So,
>
>RTT 1:
>  cwnd = SMSS
>  transmit segment 1 (SMSS-5 bytes)
>
>RTT 2:
>  ack from segment 1 arrives
>  cwnd = (2*SMSS) - 5
>  trasnmit segment 2 (SMSS-5 bytes)
>  trasnmit segment 3 (SMSS-5 bytes)
>  (5 bytes of unused cwnd left)
>
>RTT 3:
>  ack from segments 2 & 3 arrive (either as one ack packet or two)
>  cwnd = SMSS + (3 * (SMSS-5))
>       = (4*SMSS)-15
>  trasnmit segment 4 (SMSS-5 bytes)
>  trasnmit segment 5 (SMSS-5 bytes)
>  trasnmit segment 6 (SMSS-5 bytes)
>  trasnmit segment 7 (SMSS-5 bytes)
>  (5 bytes of unused cwnd left)
>
>  (note, this step assumes an ABC limit of 2*SMSS; applying L=1*SMSS
>  should be easy enough to work out)
>
>So, I don't follow the problem you're getting at here.
>
>allman
>
>
>

Mark and group,

              Sorry about the Linux implementation code, but

              within 2.6.23+ within tcp_cong.c : tcp_slow_start()
              their is the check:
              if (sysctl_tcp_abc && tp->bytes_acked < tp->mss_cache)
		return;

               below is where the congestion window increases.

               I assume this is based on the 3.3 section against
               ACk Division type attacks.

              So... If the bytes acked are just 1 byte smaller than
              the mss, this looks like the congestion window won't
              increase in size and/or we are decreasing the number
              of inflight segments.

             Is this a bug???

             Thus, if any bytes are ACKed, then minimally the two
             headers (IP & TCP), plus the interpacket gap, constitute
             some bandwidth consumption and IFF we aren't concerned
             with a "ACK Division attack", thus if their is only small
             segments transversing the wire, do we ever grow the
             congestion window? Yes, we are fighting with populating
             the pipeline with smaller sized segments generated by
             a well known networking protocol.

            Mitchell Erblich

---

From: John Heffner <[email-masked]>
Date: Mon, 17 Dec 2007 16:02:30 -0500

>              a well known networking protocol.

In the Linux implementation, the value tp->bytes_acked is cumulative 
across ACKs, not the number of bytes acknowledged by the current ACK. 
(Its value is reduced when cwnd is increased.)

If two ACKs are received of MSS-1 bytes, bytes_acked will be increased 
by 2*(MSS-1) > MSS, so the test above from the slow-start code will be 
false, and cwnd will be increased.

   -John

---

From: "Ilpo Järvinen" <[email-masked]>
Date: Tue, 18 Dec 2007 16:43:28 +0200 (EET)

On Mon, 17 Dec 2007, erblichs wrote:

>              with a "ACK Division attack",

ACK division attack won't be usable here against Linux at all because of 
FLAG_DATA_ACKED flag which is enabled for ACK only if at least one segment 
was fully acknowledge for real (i.e., not just that snd_una advanced). The 
flag is then used to guard entry to tcp_slow_start() (and tcp_cong_avoid 
as well).

>		 thus if their is only small

The problem of not getting window incremented when small segments are 
truly being sent was discussed a while ago on Linux netdev:

  http://marc.info/?t=115693258400001&r=1&w=2
  http://marc.info/?t=115738569600001&r=1&w=2

The end result being that ABC was turned off and that Linux begun to ACK 
every other segment, however, the new case has some other preconditions to 
occur as well related to the receiver buffer.

-- 
 i.