Subject: [Tsvwg] addtional weak or wording in cwnd advancement in SCTP under slow start.

From: Randall Stewart <[email-masked]>
Date: Mon, 05 Nov 2001 06:49:42 -0600

Dear all:

Janardhan has pointed out to me some weak and possibly subtle
wording in slow start for RFC2960.

We have incorporated Mark Allmans ABC in SCTP where one
never advances the cwnd UNLESS the full cwnd is used (among
other things). However under slow start the wording is
hard to spot and rather weak. It currently states:
"
   o  When cwnd is less than or equal to ssthresh an SCTP endpoint MUST
      use the slow start algorithm to increase cwnd (assuming the
                                                     ^^^^^^^^^^^^ 
      current congestion window is being fully utilized).  If an
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      incoming SACK advances the Cumulative TSN Ack Point, cwnd MUST be
      increased by at most the lesser of 1) the total size of the
      previously outstanding DATA chunk(s) acknowledged, and 2) the
      destination's path MTU. This protects against the ACK-Splitting
      attack outlined in [SAVAGE99].
"

This is rather hard to spot and weak in essence. So I propose to
add to the implementors guide the following change:

"
   o  When cwnd is less than or equal to ssthresh an SCTP endpoint MUST
      use the slow start algorithm to increase cwnd only if the
      current congestion window is being fully utilized and an
      incoming SACK advances the Cumulative TSN Ack Point. If these
      two conditions are met then cwnd MUST be increased by at most 
      the lesser of 1) the total size of the previously outstanding 
      DATA chunk(s) acknowledged, and 2) the destination's path MTU. 
      This protects against the ACK-Splitting attack outlined in
[SAVAGE99].
"

This I think will re-inforce the weak wording and make it more
apparent to the reader that BOTH conditions must be in place
BEFORE you can advance the cwnd..

Comments?

R
-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)

_______________________________________________
tsvwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/tsvwg