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

[erblichs <[e-mail]>]

Ok group,

    With the understanding that at least SOME agreement of IMPLEMENTATION
    or ARCHECTURE change should be done, and until that occurs and maybe not even after that, the default for ABC is off, so can I get some feedback on first one code snippet. Yes, again within Linux..

     Their is a comparison check for bytes acked and 2*MSS in
     the slow_start function..
     
     So, this must be obvious to someone, but in my naive way of thinking that comparison only needs to check ONLY for greater than MSS. If two small segs are implicitly each acked then they theoretically can SUM  larger than 1 MSS and be less than 2*MSS. 

     IT is not possible to ACK without loss of a previous ACK, to ACK MSS sized segment plus just a few bytes. Thus, by definition their must have been at least two partial sized segment being ACK'ed. Thus, this one ACK was a DELACK!!!!

     Right? If non MSS sized segments are sent and ACKed,, then 3 or more implicit ACKs might be necessary for 2*MSS to be valid. Right?

    Then why assume that ONLY if a DELACK is generated that it is for bytes that consume at least 2 full sized segments?

    Secondly, with a ACK clocking mechanism, and we are WANT to keep as many ACKs inflight, why wouldn't we return EARLY IFF ONLY bytes-acked was equal to 0? This would have the same fucntionality as non-ABC code, right?

   I understand about piggybacking data, and such, and in theory not wanting Nagle/almost runt sized segments as the avg sized seg in flight, but, in IPv4 we have fragmentation and most normal apps are not going to ONLY send MSS sized segs. Right?

    Should we penalize ABC for being aware of byte counts? I thought the best thing of ABC was  the ability to inform that a DELACK was for 2 previously sent segs.

     With these changes, I think I see, I think I see, a fairly decent set of performance numbers.

     Any yes, it reduces latency. But as stated in a earlier thread, that their is a tradeoff of bandwidth. However, just because we may push more
packets/segments, due to smaller sizes, I am not sure that the smaller MSS sized segments will be significant enough to decrease the packet per second rates and will actually help in low inflight conditions.

    Mitchell Erblich

     


-----Original Message-----
>From: Lars Eggert <[e-mail]>
>Sent: Dec 17, 2007 11:56 PM
>To: ext John Heffner <[e-mail]>
>Cc: erblichs <[e-mail]>, Mark Allman <[e-mail]>
>Subject: Re: [Tsvwg] Re: RFC 3465 : ABC : ACK'd Segments Just Smaller than SMSS
>
>Folks,
>
>if you want to continue this thread, please do so on [e-mail].
>
>Lars
>
>On 2007-12-17, at 23:02, ext John Heffner wrote:
>
>> erblichs wrote:
>>> -----Original Message-----
>>>> From: Mark Allman <[e-mail]>
>>>> Sent: Dec 14, 2007 7:54 PM
>>>> To: erblichs <[e-mail]>
>>>> Cc: [e-mail]
>>>> 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.
>>
>>
>> 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
>>
>>
>



_______________________________________________
tcpm mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tcpm