North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Extreme congestion (was Re: inter-domain link recovery)

  • From: Fred Baker
  • Date: Wed Aug 15 12:05:49 2007
  • Authentication-results: sj-dkim-3; [email protected]; dkim=pass (si g from cisco.com/sjdkim3002 verified; );
  • Dkim-signature: v=0.5; a=rsa-sha256; q=dns/txt; l=671; t=1187192864; x=1188056864; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; [email protected]; z=From:=20Fred=20Baker=20<[email protected]> |Subject:=20Re=3A=20Extreme=20congestion=20(was=20Re=3A=20inter-domain=20 link=20recovery) |Sender:=20; bh=whWwSptR25jlFKQJQo7J6BUTAVteCph2zs463TbU+IM=; b=mOnCjrmbkNc2BxOZ/cxwAW+lBen7UEe84+bT2Rwh+DvSKtmx23kIMNwbCx1gKeDpTCRjN/4R PANopTSG7fJ42YPQ8wUHBykNPe7X/CvAiL3rVI+CAU1kRizT55pnqjZ6;


On Aug 15, 2007, at 8:35 AM, Sean Donelan wrote:

Or should IP backbones have methods to predictably control which IP applications receive the remaining IP bandwidth? Similar to the telephone network special information tone -- All Circuits are Busy. Maybe we've found a new use for ICMP Source Quench.

Source Quench wouldn't be my favored solution here. What I might suggest is taking TCP SYN and SCTP INIT (or new sessions if they are encrypted or UDP) and put them into a lower priority/rate queue. Delaying the start of new work would have a pretty strong effect on the congestive collapse of the existing work, I should think.