From jon@Cs.Ucl.AC.UK Wed Mar 2 03:24:06 1988 Posted-Date: Wed, 02 Mar 88 11:16:22 +0000 Received-Date: Wed, 2 Mar 88 03:23:51 PST Message-Id: <8803021123.AA22728@venera.isi.edu> Received: from CS.UCL.AC.UK by venera.isi.edu (5.54/5.51) id AA22728; Wed, 2 Mar 88 03:23:51 PST Received: from pyr1.cs.ucl.ac.uk by purple.Cs.Ucl.AC.UK via Ethernet with SMTP id aa01253; 2 Mar 88 11:15 GMT To: end2end-tf@venera.isi.edu Subject: Congestion windows Date: Wed, 02 Mar 88 11:16:22 +0000 From: Jon Crowcroft Status: R On Worrying over reams of traces of SATNET data while sitting on the top deck of a 134 bus waiting for the lights to change... Acks travel faster than data (on satnet nearly twice as fast for 40 byte ack and 200 byte data), so modify the expo/linear algorithms to damp a bit further so we dont overshoot the right congestion window... so exponential could read - increase the window by packet size / ack size, per packet ack'd whilst linear could read - increase the window by packet size / ack size, per entire window ack'd (the current system increases by packet size / # packets/window per packet ack'd in the window - I'm not sure, but i think this collapses to exponential when a queue patholgically bunches acks, but is well behaved on packets, which again finds us on the wrong bit of the curve... This is indeed conservative, and could be modified by some better modelling in the tx'er of ack versus data packet propagation speeds. btw do we have any thoughts on modifying the congestion control in the presence of SACKS - one of the problems with the current SACK scheme is that we ack up to in sequence in receiver, and SACK the holes. This means we have a hard time in the transmitter working out the actual amount rx'd which is the basis for the window calculation. if we work on packet numbers, tx keeps a # for packets ack'd in sequnce rx keeps a # for packets ack'd in sequnce rx acks all packets immediately, but sets a SACK bit if they are ahead of the in seq ack number. Transmitter keeps a window of # of packets that can be sent and sends out of the end of the in order queue until some SACKs arrive. These packet #s just get stuck on the front of the in order queue, and the window operates over these plus the in order queue. The same algorithm could operate with a rate based protocol. The SACKs can close the window or reduce the rate by (lowest_SACK_number - in_order_ack_number) over (highest_outstanding_number - in_order_ack_number) or something like that, i.e. the proportion of the outstanding window (or rate) that is deemed lost. jon BTW 14 copies of a message is pretty good, but the record here was when a broken mailer sent error reports to a list when detecting duplicates - result 144 copies to everyone on the list before a 1 Gigabyte disk got full (luckily the mailer did not mail error reports about that particular problem!!) ----- End Forwarded Message -----