From owner-ecm@wyvern.aciri.org Fri Feb 2 05:01:04 2001 Received: from wyvern.aciri.org (wyvern.aciri.org [192.150.187.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA05440 for ; Fri, 2 Feb 2001 05:01:04 -0500 (EST) Received: (from majordomo@localhost) by wyvern.aciri.org (8.11.1/8.11.1) id f129w3P13290 for ecm-outgoing; Fri, 2 Feb 2001 01:58:03 -0800 (PST) (envelope-from owner-ecm@smtp.aciri.org) X-Authentication-Warning: wyvern.aciri.org: majordomo set sender to owner-ecm@smtp.aciri.org using -f Received: from www.amcc.com.cn (ppp110.hf.ah.cn [202.102.193.110]) by wyvern.aciri.org (8.11.1/8.11.1) with SMTP id f129w2X13282 for ; Fri, 2 Feb 2001 01:58:02 -0800 (PST) (envelope-from homeloan1014@aol.com) Received: (qmail 11622 invoked by uid 101); 1 Feb 2001 01:43:57 -0000 Received: from unknown (HELO aol.com) (unknown) by unknown with SMTP; 1 Feb 2001 01:43:57 -0000 From: Subject: Buying a home? Self employed? Hard to qualify? 1336 Date: Wed, 31 Jan 2001 20:28:43 Message-Id: <17.154390.715900@aol.com> Reply-To: homeloan013101@aol.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ecm@aciri.org Precedence: bulk WE SOLVE MORTGAGE PROBLEMS !!! Specializing in loans for exceptional people Self-Employed Borrowers No Income or Asset Verification All Levels of Credit Quality Up to 100% Financing High Debt Ratios Non-Owner Occupied Properties Renovation Plus Purchase and Refinance $UPER $OLUTION$ ......... $UPER RE$ULT$ If you would like additional information please email us at wed1111@excite.com?Subject=MoreInformation Help a family member or a friend with their home loan needs by FORWARDING THIS EMAIL TO THEM! An Equal Housing Opportunity Lender If you wish to be removed from this advertiser's future mailings, please reply with the subject "Remove" and this software will automatically block you from their future mailings. From owner-ecm@wyvern.aciri.org Sat Feb 3 16:21:00 2001 Received: from wyvern.aciri.org (wyvern.aciri.org [192.150.187.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11835 for ; Sat, 3 Feb 2001 16:20:59 -0500 (EST) Received: (from majordomo@localhost) by wyvern.aciri.org (8.11.1/8.11.1) id f13LFRN32701 for ecm-outgoing; Sat, 3 Feb 2001 13:15:27 -0800 (PST) (envelope-from owner-ecm@smtp.aciri.org) X-Authentication-Warning: wyvern.aciri.org: majordomo set sender to owner-ecm@smtp.aciri.org using -f Received: from mail.hosokawa.co.jp ([202.229.20.29]) by wyvern.aciri.org (8.11.1/8.11.1) with SMTP id f13LFQX32696 for ; Sat, 3 Feb 2001 13:15:26 -0800 (PST) (envelope-from bigjoe@japan.com) Received: (qmail 13011 invoked from network); 3 Feb 2001 17:58:58 -0000 Received: from 1cust46.tnt3.irving2.tx.da.uu.net (HELO 1Cust46.tnt3.irving2.tx.da.uu.net??63.24.178.46?) (63.24.178.46) by sorc3r3r.org with SMTP; 3 Feb 2001 17:58:58 -0000 Received: from kate.ccohs.ca by 1Cust46.tnt3.irving2.tx.da.uu.net with ESMTP; Sat, 03 Feb 2001 11:56:22 -0600 Message-ID: <00004c9131e4$00001630$000025fd@kate.ccohs.ca> To: From: bigjoe@japan.com Subject: Brand New E-Mail pager for FR-EE! 9725 Date: Sat, 03 Feb 2001 11:56:12 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Reply-To: bigjoe@japan.com Sender: owner-ecm@aciri.org Precedence: bulk Content-Transfer-Encoding: 7bit No long term contract No activation fee No big prepayment of airtime No credit check PAGING AMERICA is going to give you absolutely Free the Brand new Motorola Accessmate E-Mail display pager. This is the top of the line PCS technology pager made today. This side viewable display pager has a retail value of $189.00and comes with its own e-mail address so you can receive your e-mails as well as alpha-numeric and numeric messages instantly where ever you are. Your new e-mail pager has features like 50,000 character memory, message time stamping, automatic garbled message correction, beeps or vibrates, incandescent backlight, saved message folder, a unique never out of range feature that allows your pager to retrieve messages sent earlier when your pager was out of range or turned completely off. You can also receive weather, news and sports .The Motorola e-mail pager is very small and uses only a single double A battery. All we ask before we ship you your Free pager is for you to allow us to provide the airtime for you. There is no long term contract or credit check. Airtime is month to month and can be cancelled at any time. This pager will comes pre-programmed with its own e-mail address as well as a local telephone number to receive numeric pages. This pager comes with a complete 30 day money back guarantee, if after receiving this pager you're not completely happy, send it back and receive a full refund. For immediate delivery call Paging America at toll free at 877-699-8546 Brand New E-Mail pager for FREE! From owner-ecm@wyvern.aciri.org Sun Feb 4 20:46:02 2001 Received: from wyvern.aciri.org (wyvern.aciri.org [192.150.187.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13754 for ; Sun, 4 Feb 2001 20:46:01 -0500 (EST) Received: (from majordomo@localhost) by wyvern.aciri.org (8.11.1/8.11.1) id f151eu743064 for ecm-outgoing; Sun, 4 Feb 2001 17:40:56 -0800 (PST) (envelope-from owner-ecm@smtp.aciri.org) X-Authentication-Warning: wyvern.aciri.org: majordomo set sender to owner-ecm@smtp.aciri.org using -f Received: from ns1.jgn.co.jp (ns1.jgn.co.jp [211.5.100.226]) by wyvern.aciri.org (8.11.1/8.11.1) with ESMTP id f151erX43053; Sun, 4 Feb 2001 17:40:53 -0800 (PST) (envelope-from hk67hk89@yahoo.com) Received: from max1-72.losangeles.corecomm.net_[216.214.106.200] (max1-72.losangeles.corecomm.net [216.214.106.200]) by ns1.jgn.co.jp (8.8.8/3.6W) with SMTP id KAA27798; Mon, 5 Feb 2001 10:46:41 +0900 (JST) Received: from by max1-72.losangeles.corecomm.net with ESMTP; Sun, 04 Feb 2001 17:41:06 -0800 Message-ID: <00003646487b$00004649$0000577b@> To: From: hk67hk89@yahoo.com Subject: . 22395 Date: Sun, 04 Feb 2001 17:40:59 -0800 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Sender: owner-ecm@aciri.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Premier Long Distance Network - A phone company that mak= es CENTS!


vLink=3D#0000ff>

















 
  src=3D"http://www.premierldn.net/images2/PMlogo.gif" vspace=3D10 wid= th=3D359> face=3D"Arial black,Helvetica black,sans-serif" size=3D5>
YOU SAVE
20% to 50%
ON
YOUR
PHONE BILL
EACH MONTH!
  
face=3D"Arial black,Helvetica black,sans-serif" size=3D4>
. . . and we'll donate 5% of your monthly phone bill
to t= he
charity of your choice!

  • NO Monthly Service Charge!

  • NO Installation Fees!

  • Billed in 6 Second Increments!


  • Only 6.9= cent Per
    Minute Interstate 24 Hours / 7 Days a Week!


    size=3D5>SAVE 20% to 50%
    on Your Phone Bill Each Mon= th!


    href=3D"http://www.premierldn.net/images2/applicationC.gif"
    target=3Dnew>Click here to view and print form

    <= FONT
    color=3D#000000 face=3DArial size=3D2>NOTE: After the form loads o= n your
    screen, simply click the "print" button on your browser, fill out = the
    form and fax to 1-800-377-2125.

    		•

    width=3D106>






    1. No monthly service charge and no installation fees (s= avings
      $3.95 - $8.95 per month)
    2. Charges 6 second increments, not 60 seconds (savings = on
      average of 27 seconds billing on every call)
    3. Low intrastate rates (saving you money on expensive c= alls
      within your own state)
    4. Rates are the same every day and every hour - 6.9 = cent
      !       (saving you on expensive day rates of up to 25 cents per= minute)
    5. Add Toll free "800" service to existing lines or cell= phones
      at no additional installation charge or monthly fees and only = 6.9
      cent per minute interstate.

    6. Calling cards are available (16.5 cent per minute, 6-= second
      increment billing) with no NBS surcharges for your calls and n= o charge
      for the card(s).

    Sound too good to be true? Well, it's
    not . . . it's true!

    The bottom line: AT&T, =
    Sprint, MCI/Worldcom bills will be higher when all the charges are=
    added. You can easily save $100, $200, or more per year on your lo= ng
    distance bills, depending on your calling habits.

    href=3D"http://www.premierldn.net/images2/applicationC.gif"
    target=3Dnew>Click here to view and print form

    <= FONT
    color=3D#000000 face=3DArial size=3D2>NOTE: After the form loads o= n your
    screen, simply click the "print" button on your browser, fill out = the
    form and fax to 1-800-377-2125. (Federal regulations requir= e your
    signature.)

    5% of your mont= hly
    phone bill goes to help and support the following charitable
    organizations:



    • Make a Wish Foundation

    • St. Judes Children's Hospital

    • The Miracle Network

    • Compassion International

    • or the charity of YOUR choice!

    As= k for
    your toll free number(s) on the form.
    Get a calling card if yo= u
    wish.
    Don't wait, just do it today.
    You'll be glad you did!
     



    From owner-ecm@wyvern.aciri.org Mon Feb 5 13:30:45 2001 Received: from wyvern.aciri.org (wyvern.aciri.org [192.150.187.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13784 for ; Mon, 5 Feb 2001 13:30:43 -0500 (EST) Received: (from majordomo@localhost) by wyvern.aciri.org (8.11.1/8.11.1) id f15ITOb51112 for ecm-outgoing; Mon, 5 Feb 2001 10:29:24 -0800 (PST) (envelope-from owner-ecm@smtp.aciri.org) X-Authentication-Warning: wyvern.aciri.org: majordomo set sender to owner-ecm@smtp.aciri.org using -f Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by wyvern.aciri.org (8.11.1/8.11.1) with ESMTP id f15ITNX51104 for ; Mon, 5 Feb 2001 10:29:23 -0800 (PST) (envelope-from mallman@lerc.nasa.gov) Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id NAA23116; Mon, 5 Feb 2001 13:29:18 -0500 (EST) Received: from guns (mallman@localhost) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id NAA19211; Mon, 5 Feb 2001 13:30:06 -0500 (EST) Message-Id: <200102051830.NAA19211@guns.lerc.nasa.gov> To: "Rob + Helena" From: Mark Allman Reply-To: mallman@grc.nasa.gov cc: ecm@aciri.org Subject: Re: SCTP congestion control questions Organization: NASA GRC/BBN Technologies Song-of-the-Day: Selling the Drama Date: Mon, 05 Feb 2001 13:30:06 -0500 Sender: owner-ecm@aciri.org Precedence: bulk Ugh -- it is not clear that this is the place to discuss this, but... > 1. Should the SCTP fast retransmit proceedure respect cwnd/rwnd > when retransmitting a packet? > (Section 6.1 of the spec seems to state yes, but this means that FR > is not very fast :-) as it must wait for approx 1/2 a window of duplicate > SACKs to arrive before it can do the retransmit) It should ingore the rwnd, for sure. I think that since you are retransmitting you are simply replacing something in the window, not adding to it. I also think you *should* ignore cwnd (I don't remember the SCTP spec), but RFC 2581 says that you should retransmit -- I don't believe there is any mention of a check to cwnd. > 3. The FR proceedure outlined in section 7.2.4 (especially the > implementation note) seems to lead to multiple retransmits of > the same packet in the case where there is a large number of > duplicate ACKs arriving. > (counter goes to 4, packet is FR'd, counter is reset, 4+ duplicate > sacks arrive before 1 rtt => packet is FR'd again. > This of course also drastically reduces ssthresh and cwnd.) I agree this seems busted. > 4. 1 Packet loss with large windows, high bandwidth and long rtts > can lead to very large bursts of up to half a window of packets. > Does the spec (or current best practice) address this? (1 pkt > lost => cwnd =1/2 ssthresh, receiver buffer fills with 1 window of > data => a_rwnd = 0, then retransmitted pkt arrives => a_rwnd = > full size of buffers, when this SACK arrives sender can transmit > cwnd (ie 1/2 ssthresh) packets immediately) Again, I am not sure what the spec says, but you should be sending new data during the "recovery phase". After half a RTT worth of duplicate ACKs goes by you should then start sending a new (never sent) segment per duplicate ACK. Therefore, when loss recovery ends you will have outstanding data and therefore no huge burst of loss. I know this is in the SCTP document in spirit. I thought it seemed correct to me when I read it. (Also, rwnd can limit the sending of new data during recovery and cause a big burst. We might think about using something like CWV (RFC 2861) in SCTP.bis to prevent such bursts.). allman --- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ From owner-ecm@wyvern.aciri.org Mon Feb 5 22:52:49 2001 Received: from wyvern.aciri.org (wyvern.aciri.org [192.150.187.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA24905 for ; Mon, 5 Feb 2001 22:52:49 -0500 (EST) Received: (from majordomo@localhost) by wyvern.aciri.org (8.11.1/8.11.1) id f163oJk55034 for ecm-outgoing; Mon, 5 Feb 2001 19:50:19 -0800 (PST) (envelope-from owner-ecm@smtp.aciri.org) X-Authentication-Warning: wyvern.aciri.org: majordomo set sender to owner-ecm@smtp.aciri.org using -f Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by wyvern.aciri.org (8.11.1/8.11.1) with ESMTP id f163oGX55029 for ; Mon, 5 Feb 2001 19:50:16 -0800 (PST) (envelope-from Kacheong.Poon@eng.sun.com) Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA17016; Mon, 5 Feb 2001 19:50:13 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.84.31]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id TAA02415; Mon, 5 Feb 2001 19:50:12 -0800 (PST) Received: from shield (shield.Eng.Sun.COM [129.146.85.114]) by jurassic.eng.sun.com (8.11.2+Sun/8.11.2) with SMTP id f163oBR314587; Mon, 5 Feb 2001 19:50:11 -0800 (PST) Date: Mon, 5 Feb 2001 19:50:27 -0800 (PST) From: Kacheong Poon Reply-To: Kacheong Poon Subject: Re: SCTP congestion control questions To: mallman@grc.nasa.gov Cc: Rob + Helena , ecm@aciri.org In-Reply-To: "Your message with ID" <200102051830.NAA19211@guns.lerc.nasa.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ecm@aciri.org Precedence: bulk > I also think you *should* ignore cwnd (I don't remember the SCTP > spec), but RFC 2581 says that you should retransmit -- I don't > believe there is any mention of a check to cwnd. One important note on this is the stack should avoid sending a burst of traffic in retransmission, even it ignores cwnd and rwnd. For example, in TCP, SACK info can tell the stack that more than half of the window's data is lost (only the last 3 segments are received). The stack should not fast retransmit the whole half window at once. I remember (I may be mistaken) that the original new Reno which is based on the work by J. Hoe, the stack uses something similar to "slow start" in the fast retransmit phase to recover more than 1 lost segment in 1 RTT. Anyway, when the spec is not clear, the implementor should use a good judgement on how the SCTP fast retransmit behavior should be like. I believe there is enough info on all those RFCs which can be used to make a good decision. K. Poon. kcpoon@eng.sun.com From owner-ecm@wyvern.aciri.org Tue Feb 6 09:17:14 2001 Received: from wyvern.aciri.org (wyvern.aciri.org [192.150.187.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14632 for ; Tue, 6 Feb 2001 09:17:13 -0500 (EST) Received: (from majordomo@localhost) by wyvern.aciri.org (8.11.1/8.11.1) id f16EGHV58997 for ecm-outgoing; Tue, 6 Feb 2001 06:16:17 -0800 (PST) (envelope-from owner-ecm@smtp.aciri.org) X-Authentication-Warning: wyvern.aciri.org: majordomo set sender to owner-ecm@smtp.aciri.org using -f Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by wyvern.aciri.org (8.11.1/8.11.1) with ESMTP id f16EGGX58992 for ; Tue, 6 Feb 2001 06:16:16 -0800 (PST) (envelope-from mallman@lerc.nasa.gov) Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id JAA20455; Tue, 6 Feb 2001 09:16:15 -0500 (EST) Received: from guns (mallman@localhost) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id JAA03794; Tue, 6 Feb 2001 09:17:05 -0500 (EST) Message-Id: <200102061417.JAA03794@guns.lerc.nasa.gov> To: Kacheong Poon From: Mark Allman Reply-To: mallman@grc.nasa.gov cc: Rob + Helena , ecm@aciri.org Subject: Re: SCTP congestion control questions Organization: NASA GRC/BBN Technologies Song-of-the-Day: Ticket to Ride Date: Tue, 06 Feb 2001 09:17:05 -0500 Sender: owner-ecm@aciri.org Precedence: bulk > One important note on this is the stack should avoid sending a > burst of traffic in retransmission, even it ignores cwnd and rwnd. > For example, in TCP, SACK info can tell the stack that more than > half of the window's data is lost (only the last 3 segments are > received). The stack should not fast retransmit the whole half > window at once. Definatly! > I remember (I may be mistaken) that the original new Reno which is > based on the work by J. Hoe, the stack uses something similar to > "slow start" in the fast retransmit phase to recover more than 1 > lost segment in 1 RTT. As I remember it, SCTP uses SACK by default and therefore doesn't really have a newreno-like mechanism. > Anyway, when the spec is not clear, the implementor should use a > good judgement on how the SCTP fast retransmit behavior should be > like. I believe there is enough info on all those RFCs which can > be used to make a good decision. Agreed. allman --- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ From owner-ecm@wyvern.aciri.org Tue Feb 6 12:51:42 2001 Received: from wyvern.aciri.org (wyvern.aciri.org [192.150.187.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25052 for ; Tue, 6 Feb 2001 12:51:41 -0500 (EST) Received: (from majordomo@localhost) by wyvern.aciri.org (8.11.1/8.11.1) id f16Hoqc61922 for ecm-outgoing; Tue, 6 Feb 2001 09:50:52 -0800 (PST) (envelope-from owner-ecm@smtp.aciri.org) X-Authentication-Warning: wyvern.aciri.org: majordomo set sender to owner-ecm@smtp.aciri.org using -f Received: from stewart.chicago.il.us (dsl-64-128-23-213.telocity.com [64.128.23.213]) by wyvern.aciri.org (8.11.1/8.11.1) with ESMTP id f16HopX61917 for ; Tue, 6 Feb 2001 09:50:51 -0800 (PST) (envelope-from randall@stewart.chicago.il.us) Received: from stewart.chicago.il.us (IDENT:randall@stewart.chicago.il.us [10.1.1.1]) by stewart.chicago.il.us (8.9.3/8.8.7) with ESMTP id LAA13240; Tue, 6 Feb 2001 11:51:27 -0600 Message-ID: <3A80399E.5D59D2E8@stewart.chicago.il.us> Date: Tue, 06 Feb 2001 11:51:26 -0600 From: "Randall R. Stewart" X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: mallman@grc.nasa.gov CC: Rob + Helena , ecm@aciri.org Subject: Re: SCTP congestion control questions References: <200102051830.NAA19211@guns.lerc.nasa.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ecm@aciri.org Precedence: bulk Content-Transfer-Encoding: 7bit Mark: Some comments below... Mark Allman wrote: > > Ugh -- it is not clear that this is the place to discuss this, > but... > > > 1. Should the SCTP fast retransmit proceedure respect cwnd/rwnd > > when retransmitting a packet? > > (Section 6.1 of the spec seems to state yes, but this means that FR > > is not very fast :-) as it must wait for approx 1/2 a window of duplicate > > SACKs to arrive before it can do the retransmit) > > It should ingore the rwnd, for sure. I think that since you are > retransmitting you are simply replacing something in the window, not > adding to it. > I don't think the rwnd is ever an issue. Since when you do a FR you: A) Add back the packet to the rwnd you have left and B) Then go to do the FR.. So you never should hit the problem that the FR is gated by the rwnd... as long as you FR right away :/ > I also think you *should* ignore cwnd (I don't remember the SCTP > spec), but RFC 2581 says that you should retransmit -- I don't > believe there is any mention of a check to cwnd. I believe this may be broke in the spec. I have re-issued the bake-off draft to include this item. > > > 3. The FR proceedure outlined in section 7.2.4 (especially the > > implementation note) seems to lead to multiple retransmits of > > the same packet in the case where there is a large number of > > duplicate ACKs arriving. > > (counter goes to 4, packet is FR'd, counter is reset, 4+ duplicate > > sacks arrive before 1 rtt => packet is FR'd again. > > This of course also drastically reduces ssthresh and cwnd.) > > I agree this seems busted. Yep, this is also listed to be fixed in the BIS (in the bake-off draft). > > > 4. 1 Packet loss with large windows, high bandwidth and long rtts > > can lead to very large bursts of up to half a window of packets. > > Does the spec (or current best practice) address this? (1 pkt > > lost => cwnd =1/2 ssthresh, receiver buffer fills with 1 window of > > data => a_rwnd = 0, then retransmitted pkt arrives => a_rwnd = > > full size of buffers, when this SACK arrives sender can transmit > > cwnd (ie 1/2 ssthresh) packets immediately) > > Again, I am not sure what the spec says, but you should be sending > new data during the "recovery phase". After half a RTT worth of > duplicate ACKs goes by you should then start sending a new (never > sent) segment per duplicate ACK. Therefore, when loss recovery ends > you will have outstanding data and therefore no huge burst of loss. > I know this is in the SCTP document in spirit. I thought it seemed > correct to me when I read it. > > (Also, rwnd can limit the sending of new data during recovery and > cause a big burst. We might think about using something like CWV > (RFC 2861) in SCTP.bis to prevent such bursts.). Two things to note: A) Yes you should start sending new data (if you have more data to send of course) 1/2 window later.. B) I believe the effect of RFC2861 is already present (at least in theory). If you do NOT start sending new data, you will by definition be "idle", and if you are idle you are to begin halving your cwnd value... Another thing we could do just to be a bit cautious is to do what Kevin/Sally suggestin "Simulation-based Comparisons of Tahoe, Reno and SACK TCP" .. i.e. have a "maxBurst" value that will apply after a FR has been acked. This would in theory never be a problem if A and B are working... so it would be harmless to add it in as a safety measure... I have done so in the next release of the ref-implementation :) R > > allman > > --- > Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ -- Randall R. Stewart randall@stewart.chicago.il.us or rrs@cisco.com 815-342-5222 (cell) 815-477-2127 (work) From owner-ecm@wyvern.aciri.org Tue Feb 6 12:53:53 2001 Received: from wyvern.aciri.org (wyvern.aciri.org [192.150.187.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25171 for ; Tue, 6 Feb 2001 12:53:52 -0500 (EST) Received: (from majordomo@localhost) by wyvern.aciri.org (8.11.1/8.11.1) id f16HrmH61954 for ecm-outgoing; Tue, 6 Feb 2001 09:53:48 -0800 (PST) (envelope-from owner-ecm@smtp.aciri.org) X-Authentication-Warning: wyvern.aciri.org: majordomo set sender to owner-ecm@smtp.aciri.org using -f Received: from stewart.chicago.il.us (dsl-64-128-23-213.telocity.com [64.128.23.213]) by wyvern.aciri.org (8.11.1/8.11.1) with ESMTP id f16HrlX61949 for ; Tue, 6 Feb 2001 09:53:47 -0800 (PST) (envelope-from randall@stewart.chicago.il.us) Received: from stewart.chicago.il.us (IDENT:randall@stewart.chicago.il.us [10.1.1.1]) by stewart.chicago.il.us (8.9.3/8.8.7) with ESMTP id LAA13249; Tue, 6 Feb 2001 11:54:31 -0600 Message-ID: <3A803A57.E02C3829@stewart.chicago.il.us> Date: Tue, 06 Feb 2001 11:54:31 -0600 From: "Randall R. Stewart" X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Kacheong Poon CC: mallman@grc.nasa.gov, Rob + Helena , ecm@aciri.org Subject: Re: SCTP congestion control questions References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ecm@aciri.org Precedence: bulk Content-Transfer-Encoding: 7bit Kacheong: A minor comment. Kacheong Poon wrote: > > > I also think you *should* ignore cwnd (I don't remember the SCTP > > spec), but RFC 2581 says that you should retransmit -- I don't > > believe there is any mention of a check to cwnd. > > One important note on this is the stack should avoid sending a burst > of traffic in retransmission, even it ignores cwnd and rwnd. For > example, in TCP, SACK info can tell the stack that more than half of > the window's data is lost (only the last 3 segments are received). > The stack should not fast retransmit the whole half window at once. > You are never allowed (according to RFC2960) to send more than ONE single packet at the time a retransmit is determined... either by FR or T-O. So for any one feedback event/SACK you should never respond with more than one RETRANSMIT... R > I remember (I may be mistaken) that the original new Reno which is > based on the work by J. Hoe, the stack uses something similar to "slow > start" in the fast retransmit phase to recover more than 1 lost segment > in 1 RTT. > > Anyway, when the spec is not clear, the implementor should use a > good judgement on how the SCTP fast retransmit behavior should be like. > I believe there is enough info on all those RFCs which can be used to > make a good decision. > > K. Poon. > kcpoon@eng.sun.com -- Randall R. Stewart randall@stewart.chicago.il.us or rrs@cisco.com 815-342-5222 (cell) 815-477-2127 (work) From owner-ecm@wyvern.aciri.org Tue Feb 6 13:12:12 2001 Received: from wyvern.aciri.org (wyvern.aciri.org [192.150.187.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26316 for ; Tue, 6 Feb 2001 13:12:11 -0500 (EST) Received: (from majordomo@localhost) by wyvern.aciri.org (8.11.1/8.11.1) id f16IC4Q62123 for ecm-outgoing; Tue, 6 Feb 2001 10:12:04 -0800 (PST) (envelope-from owner-ecm@smtp.aciri.org) X-Authentication-Warning: wyvern.aciri.org: majordomo set sender to owner-ecm@smtp.aciri.org using -f Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by wyvern.aciri.org (8.11.1/8.11.1) with ESMTP id f16IC4X62118 for ; Tue, 6 Feb 2001 10:12:04 -0800 (PST) (envelope-from touch@ISI.EDU) Received: from isi.edu (sci.isi.edu [128.9.160.93]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id KAA11029; Tue, 6 Feb 2001 10:11:54 -0800 (PST) Message-ID: <3A803E66.D918D04D@isi.edu> Date: Tue, 06 Feb 2001 10:11:50 -0800 From: Joe Touch X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "Randall R. Stewart" CC: mallman@grc.nasa.gov, Rob + Helena , ecm@aciri.org Subject: Re: SCTP congestion control questions References: <200102051830.NAA19211@guns.lerc.nasa.gov> <3A80399E.5D59D2E8@stewart.chicago.il.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ecm@aciri.org Precedence: bulk Content-Transfer-Encoding: 7bit "Randall R. Stewart" wrote: > > Another thing we could do just to be a bit cautious is to > do what Kevin/Sally suggestin "Simulation-based Comparisons of > Tahoe, Reno and SACK TCP" .. i.e. have a "maxBurst" value that > will apply after a FR has been acked. This would in theory never > be a problem if A and B are working... so it would be harmless > to add it in as a safety measure... I have done so in the > next release of the ref-implementation :) There is a variant of maxburst called burst-or-lose (Touch/Floyd) that combines the need to avoiding bursts due to retransmissions and avoiding bursts after idle periods. It was described in an old ID, which is still somewhat in process (though not active). An archived version of the ID is at: http://www.isi.edu/touch/pubs/tcpimpl-restart-01.txt (from an email of mine from back in Sept): > ...regarding MaxBurst, > Sally's version was a 'per send call' limit. It assumes that "send" is called > on every ACK or timeout event (an implementation detail), and limits only > stretch-ACK related bursts. MaxBurst: > > - resets the count inside the send-call to N=5 > > The variant called Burst or Lose" (in the earlier e-mail) augments MaxBurst > in a few ways: > > - it retains the count (N=3 or N=5) between send-call invocations > - it resets the count on ACKs (not dupacks, though) and timeouts > this is a 'reset to N' - it doesn't increment beyond N > > The goal of BOL is twofold: > > - avoid stretch-ACK bursts > - avoid bursts due to source stream burstiness (idle then active) > > Joe From owner-ecm@wyvern.aciri.org Tue Feb 6 13:25:51 2001 Received: from wyvern.aciri.org (wyvern.aciri.org [192.150.187.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27063 for ; Tue, 6 Feb 2001 13:25:50 -0500 (EST) Received: (from majordomo@localhost) by wyvern.aciri.org (8.11.1/8.11.1) id f16IPSO62238 for ecm-outgoing; Tue, 6 Feb 2001 10:25:28 -0800 (PST) (envelope-from owner-ecm@smtp.aciri.org) X-Authentication-Warning: wyvern.aciri.org: majordomo set sender to owner-ecm@smtp.aciri.org using -f Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by wyvern.aciri.org (8.11.1/8.11.1) with ESMTP id f16IPRX62233 for ; Tue, 6 Feb 2001 10:25:27 -0800 (PST) (envelope-from mallman@lerc.nasa.gov) Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id NAA10381; Tue, 6 Feb 2001 13:25:19 -0500 (EST) Received: from guns (mallman@localhost) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id NAA06092; Tue, 6 Feb 2001 13:26:09 -0500 (EST) Message-Id: <200102061826.NAA06092@guns.lerc.nasa.gov> To: "Randall R. Stewart" From: Mark Allman Reply-To: mallman@grc.nasa.gov cc: Rob + Helena , ecm@aciri.org Subject: Re: SCTP congestion control questions Organization: NASA GRC/BBN Technologies Song-of-the-Day: Ticket to Ride Date: Tue, 06 Feb 2001 13:26:09 -0500 Sender: owner-ecm@aciri.org Precedence: bulk > A) Yes you should start sending new data (if you have more data > to send of course) 1/2 window later.. Right. > B) I believe the effect of RFC2861 is already present (at least > in theory). If you do NOT start sending new data, you will > by definition be "idle", and if you are idle you are to > begin halving your cwnd value... OK. > Another thing we could do just to be a bit cautious is to do what > Kevin/Sally suggestin "Simulation-based Comparisons of Tahoe, Reno > and SACK TCP" .. i.e. have a "maxBurst" value that will apply > after a FR has been acked. This would in theory never be a problem > if A and B are working... so it would be harmless to add it in as > a safety measure... I have done so in the next release of the > ref-implementation :) I have never been convinced that I should be a huge fan of such blanket mechanisms. My hit is that if there is a situation that causes these bursts, we should fix the root cause. allman From owner-ecm@wyvern.aciri.org Tue Feb 6 13:34:17 2001 Received: from wyvern.aciri.org (wyvern.aciri.org [192.150.187.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27366 for ; Tue, 6 Feb 2001 13:34:16 -0500 (EST) Received: (from majordomo@localhost) by wyvern.aciri.org (8.11.1/8.11.1) id f16IXlN62330 for ecm-outgoing; Tue, 6 Feb 2001 10:33:47 -0800 (PST) (envelope-from owner-ecm@smtp.aciri.org) X-Authentication-Warning: wyvern.aciri.org: majordomo set sender to owner-ecm@smtp.aciri.org using -f Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by wyvern.aciri.org (8.11.1/8.11.1) with ESMTP id f16IXlX62325 for ; Tue, 6 Feb 2001 10:33:47 -0800 (PST) (envelope-from touch@ISI.EDU) Received: from isi.edu (sci.isi.edu [128.9.160.93]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id KAA14273; Tue, 6 Feb 2001 10:33:17 -0800 (PST) Message-ID: <3A804369.FDE67752@isi.edu> Date: Tue, 06 Feb 2001 10:33:13 -0800 From: Joe Touch X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: mallman@grc.nasa.gov CC: "Randall R. Stewart" , Rob + Helena , ecm@aciri.org Subject: Re: SCTP congestion control questions References: <200102061826.NAA06092@guns.lerc.nasa.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ecm@aciri.org Precedence: bulk Content-Transfer-Encoding: 7bit Mark Allman wrote: > > > Another thing we could do just to be a bit cautious is to do what > > Kevin/Sally suggestin "Simulation-based Comparisons of Tahoe, Reno > > and SACK TCP" .. i.e. have a "maxBurst" value that will apply > > after a FR has been acked. This would in theory never be a problem > > if A and B are working... so it would be harmless to add it in as > > a safety measure... I have done so in the next release of the > > ref-implementation :) > > I have never been convinced that I should be a huge fan of such > blanket mechanisms. My hit is that if there is a situation that > causes these bursts, we should fix the root cause. The root cause is that bursting is the result of implementation decisions that are not otherwise prohibited by the protocol. Using Sally's "don't overspecify", the goal of Burst-or-lose was to put exactly enough protocol mechanism in place to prevent accumulation of 'permission to send', which is otherwise not prohibited by the protocol. Joe From owner-ecm@wyvern.aciri.org Tue Feb 6 13:43:01 2001 Received: from wyvern.aciri.org (wyvern.aciri.org [192.150.187.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27621 for ; Tue, 6 Feb 2001 13:43:00 -0500 (EST) Received: (from majordomo@localhost) by wyvern.aciri.org (8.11.1/8.11.1) id f16IgkG62436 for ecm-outgoing; Tue, 6 Feb 2001 10:42:46 -0800 (PST) (envelope-from owner-ecm@smtp.aciri.org) X-Authentication-Warning: wyvern.aciri.org: majordomo set sender to owner-ecm@smtp.aciri.org using -f Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by wyvern.aciri.org (8.11.1/8.11.1) with ESMTP id f16IgjX62431 for ; Tue, 6 Feb 2001 10:42:45 -0800 (PST) (envelope-from mallman@lerc.nasa.gov) Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id NAA15215; Tue, 6 Feb 2001 13:42:44 -0500 (EST) Received: from guns (mallman@localhost) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id NAA06372; Tue, 6 Feb 2001 13:43:35 -0500 (EST) Message-Id: <200102061843.NAA06372@guns.lerc.nasa.gov> To: Joe Touch From: Mark Allman Reply-To: mallman@grc.nasa.gov cc: "Randall R. Stewart" , Rob + Helena , ecm@aciri.org Subject: Re: SCTP congestion control questions Organization: NASA GRC/BBN Technologies Song-of-the-Day: Ticket to Ride Date: Tue, 06 Feb 2001 13:43:34 -0500 Sender: owner-ecm@aciri.org Precedence: bulk > The root cause is that bursting is the result of implementation > decisions that are not otherwise prohibited by the protocol. Right. Why not fix these bad decisions? (Yes, there is a good chance this is simply philosophical). allman --- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ From owner-ecm@wyvern.aciri.org Tue Feb 6 13:47:06 2001 Received: from wyvern.aciri.org (wyvern.aciri.org [192.150.187.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27712 for ; Tue, 6 Feb 2001 13:47:05 -0500 (EST) Received: (from majordomo@localhost) by wyvern.aciri.org (8.11.1/8.11.1) id f16Il1962490 for ecm-outgoing; Tue, 6 Feb 2001 10:47:01 -0800 (PST) (envelope-from owner-ecm@smtp.aciri.org) X-Authentication-Warning: wyvern.aciri.org: majordomo set sender to owner-ecm@smtp.aciri.org using -f Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by wyvern.aciri.org (8.11.1/8.11.1) with ESMTP id f16Il1X62485 for ; Tue, 6 Feb 2001 10:47:01 -0800 (PST) (envelope-from touch@ISI.EDU) Received: from isi.edu (sci.isi.edu [128.9.160.93]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id KAA15900; Tue, 6 Feb 2001 10:46:56 -0800 (PST) Message-ID: <3A80469C.3E756FE4@isi.edu> Date: Tue, 06 Feb 2001 10:46:52 -0800 From: Joe Touch X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: mallman@grc.nasa.gov CC: "Randall R. Stewart" , Rob + Helena , ecm@aciri.org Subject: Re: SCTP congestion control questions References: <200102061843.NAA06372@guns.lerc.nasa.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ecm@aciri.org Precedence: bulk Content-Transfer-Encoding: 7bit Mark Allman wrote: > > > The root cause is that bursting is the result of implementation > > decisions that are not otherwise prohibited by the protocol. > > Right. Why not fix these bad decisions? (Yes, there is a good > chance this is simply philosophical). Depends on what is 'wrong'. If it is the behavior that is wrong (bursting), then fix the behavior (burst limit). I'm not clear there is a fundamental reason behind causing a burst; it's a symptom, and it seems appropriate to treat the symptom. Otherwise we're back-tracking 'intent' - anything that _might_ result in an implementation that _might_ end up bursting is deemed 'wrong'. Sometimes cold medicine is exactly what you want. Joe From owner-ecm@wyvern.aciri.org Tue Feb 6 16:25:58 2001 Received: from wyvern.aciri.org (wyvern.aciri.org [192.150.187.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02440 for ; Tue, 6 Feb 2001 16:25:56 -0500 (EST) Received: (from majordomo@localhost) by wyvern.aciri.org (8.11.1/8.11.1) id f16LOlu63890 for ecm-outgoing; Tue, 6 Feb 2001 13:24:47 -0800 (PST) (envelope-from owner-ecm@smtp.aciri.org) X-Authentication-Warning: wyvern.aciri.org: majordomo set sender to owner-ecm@smtp.aciri.org using -f Received: from stewart.chicago.il.us (dsl-64-128-23-213.telocity.com [64.128.23.213]) by wyvern.aciri.org (8.11.1/8.11.1) with ESMTP id f16LOkX63885 for ; Tue, 6 Feb 2001 13:24:46 -0800 (PST) (envelope-from randall@stewart.chicago.il.us) Received: from stewart.chicago.il.us (IDENT:randall@stewart.chicago.il.us [10.1.1.1]) by stewart.chicago.il.us (8.9.3/8.8.7) with ESMTP id PAA13844; Tue, 6 Feb 2001 15:25:26 -0600 Message-ID: <3A806BC6.79D59079@stewart.chicago.il.us> Date: Tue, 06 Feb 2001 15:25:26 -0600 From: "Randall R. Stewart" X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Joe Touch CC: mallman@grc.nasa.gov, Rob + Helena , ecm@aciri.org Subject: Re: SCTP congestion control questions References: <200102061843.NAA06372@guns.lerc.nasa.gov> <3A80469C.3E756FE4@isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ecm@aciri.org Precedence: bulk Content-Transfer-Encoding: 7bit Mark/Joe: One thing to remember on this "burst" is the fact that this all supposedly occurs (if I remember right from reading Rob's work... Rob help my feeble overloaded mind here :->) .. is it occurs in one RTT. So, thinking on it, none of the reductions may have taken place.. but of course you would have to have a very strange occurance in that A) The application would not have more data to clock out (as you point out Mark). and B) Just has the FR's ACK arrives the application would have to have this "Burst" of new data. These two things seem to me to be unlikely but I don't see how other than by having a maxBurst you can gate this strange behavior.... And I am sorry Joe, I have not read your draft :< I have pulled it down.. but alas I fear it will be a while before I can spare the cycles ... R Joe Touch wrote: > > Mark Allman wrote: > > > > > The root cause is that bursting is the result of implementation > > > decisions that are not otherwise prohibited by the protocol. > > > > Right. Why not fix these bad decisions? (Yes, there is a good > > chance this is simply philosophical). > > Depends on what is 'wrong'. > > If it is the behavior that is wrong (bursting), then > fix the behavior (burst limit). > > I'm not clear there is a fundamental reason behind > causing a burst; it's a symptom, and it seems > appropriate to treat the symptom. > > Otherwise we're back-tracking 'intent' - anything that _might_ > result in an implementation that _might_ end up bursting is > deemed 'wrong'. > > Sometimes cold medicine is exactly what you want. > > Joe -- Randall R. Stewart randall@stewart.chicago.il.us or rrs@cisco.com 815-342-5222 (cell) 815-477-2127 (work) From owner-ecm@wyvern.aciri.org Tue Feb 6 16:50:22 2001 Received: from wyvern.aciri.org (wyvern.aciri.org [192.150.187.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA03025 for ; Tue, 6 Feb 2001 16:50:21 -0500 (EST) Received: (from majordomo@localhost) by wyvern.aciri.org (8.11.1/8.11.1) id f16LoEH64070 for ecm-outgoing; Tue, 6 Feb 2001 13:50:14 -0800 (PST) (envelope-from owner-ecm@smtp.aciri.org) X-Authentication-Warning: wyvern.aciri.org: majordomo set sender to owner-ecm@smtp.aciri.org using -f Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by wyvern.aciri.org (8.11.1/8.11.1) with ESMTP id f16LoDX64065 for ; Tue, 6 Feb 2001 13:50:13 -0800 (PST) (envelope-from touch@ISI.EDU) Received: from isi.edu (sci.isi.edu [128.9.160.93]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id NAA06872; Tue, 6 Feb 2001 13:48:37 -0800 (PST) Message-ID: <3A807131.7A14D064@isi.edu> Date: Tue, 06 Feb 2001 13:48:33 -0800 From: Joe Touch X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "Randall R. Stewart" CC: mallman@grc.nasa.gov, Rob + Helena , ecm@aciri.org Subject: Re: SCTP congestion control questions References: <200102061843.NAA06372@guns.lerc.nasa.gov> <3A80469C.3E756FE4@isi.edu> <3A806BC6.79D59079@stewart.chicago.il.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ecm@aciri.org Precedence: bulk Content-Transfer-Encoding: 7bit "Randall R. Stewart" wrote: > > Mark/Joe: > > One thing to remember on this "burst" is the > fact that this all supposedly occurs (if I remember > right from reading Rob's work... Rob help my > feeble overloaded mind here :->) .. is it > occurs in one RTT. So, thinking on it, none > of the reductions may have taken place.. but of > course you would have to have a very strange occurance > in that > > A) The application would not have more data to clock > out (as you point out Mark). > > and > > B) Just has the FR's ACK arrives the application would > have to have this "Burst" of new data. > > These two things seem to me to be unlikely but I don't > see how other than by having a maxBurst you can gate > this strange behavior.... FWIW, maxburst limits per-event - which means a bad implementation can have the application keep doing send calls, each of which can burst. The idea of BOL was to gate the behavior with more of a leaky-bucket - refilled when an ACK arrives, and drained when packets are sent. There are subtle differences, but they are basically similar in how they gate things, and both are proactive, not reactive. Joe From owner-ecm@wyvern.aciri.org Tue Feb 6 19:13:51 2001 Received: from wyvern.aciri.org (wyvern.aciri.org [192.150.187.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA05015 for ; Tue, 6 Feb 2001 19:13:50 -0500 (EST) Received: (from majordomo@localhost) by wyvern.aciri.org (8.11.1/8.11.1) id f170D6p65027 for ecm-outgoing; Tue, 6 Feb 2001 16:13:06 -0800 (PST) (envelope-from owner-ecm@smtp.aciri.org) X-Authentication-Warning: wyvern.aciri.org: majordomo set sender to owner-ecm@smtp.aciri.org using -f Received: from mail.iol.ie (mail2.mail.iol.ie [194.125.2.193]) by wyvern.aciri.org (8.11.1/8.11.1) with ESMTP id f170D4X65022 for ; Tue, 6 Feb 2001 16:13:04 -0800 (PST) (envelope-from brennanr@iol.ie) Received: from antioch ([194.165.163.76]) by mail.iol.ie Sendmail (v8.9.3) with ESMTP id AAA72729; Wed, 7 Feb 2001 00:12:11 GMT Message-Id: <200102070012.AAA72729@mail.iol.ie> From: "Rob + Helena" To: "Randall R. Stewart" , "Joe Touch" Cc: , Subject: Re: SCTP congestion control questions Date: Wed, 7 Feb 2001 00:15:47 -0000 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1162 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ecm@aciri.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi all ---------- > From: Randall R. Stewart > > Mark/Joe: > > One thing to remember on this "burst" is the > fact that this all supposedly occurs (if I remember > right from reading Rob's work... Rob help my > feeble overloaded mind here :->) .. is it > occurs in one RTT. So, thinking on it, none > of the reductions may have taken place.. but of > course you would have to have a very strange occurance > in that > > A) The application would not have more data to clock > out (as you point out Mark). > > and > > B) Just has the FR's ACK arrives the application would > have to have this "Burst" of new data. > > These two things seem to me to be unlikely but I don't > see how other than by having a maxBurst you can gate > this strange behavior.... If anyone is interested I have put a figure illustrating a SCTP burst after recovery at: http://www.teltec.dcu.ie/~brennanr/sctp.html This comes from my simulation model of SCTP running over a long delay/high bandwidth link with a droptail gateway with short qs. I think that Randal is correct about the non-decay of cwnd as in the figure we are sending at least 1 pkt per rtt (in fact the decay is linked to rto rather than rtt directly and these may be different after a loss). On the topic of clocking out more data during recovery: Note that when FR retransmission occurs there is already a window of data in flight. This is all out of order so is buffered at the receiver => a_rwnd is reduced to 0. This means that the sender is rwnd rather than cwnd limited. When the SACK for the FR'd pkt arrives the q'd data hasn't yet been sent to the application so a_rwnd is still 0. No data is in flight so the sender can then send just one more packet. the SACK for this has a_rwnd = window size. When the receiver gets this it is no longer rwnd limited => it can send up to cwnd of data. Cwnd was set to half of the max window when the FR occured => 1/2 a window of data is sent. rgds rob From owner-ecm@wyvern.aciri.org Tue Feb 6 19:13:55 2001 Received: from wyvern.aciri.org (wyvern.aciri.org [192.150.187.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA05026 for ; Tue, 6 Feb 2001 19:13:54 -0500 (EST) Received: (from majordomo@localhost) by wyvern.aciri.org (8.11.1/8.11.1) id f170DoS65043 for ecm-outgoing; Tue, 6 Feb 2001 16:13:50 -0800 (PST) (envelope-from owner-ecm@smtp.aciri.org) X-Authentication-Warning: wyvern.aciri.org: majordomo set sender to owner-ecm@smtp.aciri.org using -f Received: from mail.iol.ie (mail2.mail.iol.ie [194.125.2.193]) by wyvern.aciri.org (8.11.1/8.11.1) with ESMTP id f170DmX65038 for ; Tue, 6 Feb 2001 16:13:49 -0800 (PST) (envelope-from brennanr@iol.ie) Received: from antioch ([194.165.163.76]) by mail.iol.ie Sendmail (v8.9.3) with ESMTP id AAA72708; Wed, 7 Feb 2001 00:12:02 GMT Message-Id: <200102070012.AAA72708@mail.iol.ie> From: "Rob + Helena" To: , "Joe Touch" Cc: "Randall R. Stewart" , Subject: Re: SCTP congestion control questions Date: Tue, 6 Feb 2001 23:30:14 -0000 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1162 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ecm@aciri.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi All ---------- > From: Mark Allman > > > The root cause is that bursting is the result of implementation > > decisions that are not otherwise prohibited by the protocol. > > Right. Why not fix these bad decisions? (Yes, there is a good > chance this is simply philosophical). I'm not sure what you are implying here, that implementors should fix their code or that we should fix the spec. As a relative newcomer to TCP/SCTP congestion control, my (perhaps naive) opinion is: if the protocol specification is sufficiently loose that a problem like bursts can occur with poor "implementation decisions" then we should develop a minimally intrusive fix to the protocol specification that prevents this behaviour for conformant implementations. This area of protocol stack development is sufficiently obtuse that these problems won't become obvious until after deployment (or at least some very rigourous testing). rgds rob From owner-ecm@wyvern.aciri.org Tue Feb 6 20:30:12 2001 Received: from wyvern.aciri.org (wyvern.aciri.org [192.150.187.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05726 for ; Tue, 6 Feb 2001 20:30:11 -0500 (EST) Received: (from majordomo@localhost) by wyvern.aciri.org (8.11.1/8.11.1) id f171TOB65568 for ecm-outgoing; Tue, 6 Feb 2001 17:29:24 -0800 (PST) (envelope-from owner-ecm@smtp.aciri.org) X-Authentication-Warning: wyvern.aciri.org: majordomo set sender to owner-ecm@smtp.aciri.org using -f Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by wyvern.aciri.org (8.11.1/8.11.1) with ESMTP id f171TNX65563 for ; Tue, 6 Feb 2001 17:29:23 -0800 (PST) (envelope-from Kacheong.Poon@eng.sun.com) Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA12903; Tue, 6 Feb 2001 17:29:15 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.87.31]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id RAA20663; Tue, 6 Feb 2001 17:29:14 -0800 (PST) Received: from shield (shield.Eng.Sun.COM [129.146.85.114]) by jurassic.eng.sun.com (8.11.2+Sun/8.11.2) with SMTP id f171T9R525137; Tue, 6 Feb 2001 17:29:09 -0800 (PST) Date: Tue, 6 Feb 2001 17:29:25 -0800 (PST) From: Kacheong Poon Reply-To: Kacheong Poon Subject: Re: SCTP congestion control questions To: Rob + Helena Cc: mallman@grc.nasa.gov, Joe Touch , "Randall R. Stewart" , ecm@aciri.org In-Reply-To: "Your message with ID" <200102070012.AAA72708@mail.iol.ie> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ecm@aciri.org Precedence: bulk > As a relative newcomer to TCP/SCTP congestion control, my (perhaps > naive) opinion is: > if the protocol specification is sufficiently loose that a problem like > bursts > can occur with poor "implementation decisions" then we should develop > a minimally intrusive fix to the protocol specification that prevents this > behaviour for conformant implementations. I share your concern as an implementor. But sometimes, IMHO BTW, that there is a gray area. In this particular case, I believe an implementation can have several ways to avoid the problem. And any of those ways will not cause interoperability problem. So should a solution be specified in the protocol as long as the problem is clearly specified? Or should this be an implementation choice? > This area of protocol stack development is sufficiently obtuse that > these problems won't become obvious until after deployment (or > at least some very rigourous testing). Again in this particular case, this is a well known problem such that most, if not all, TCP stacks out there have some form of remedy. So people implementing SCTP should learn from past experience of TCP. I agree that there can be other problems which will not be found without rigorous testing. This is a reason why some people think that a transport protocol needs several years of real life experience to be called stable... K. Poon. kcpoon@eng.sun.com From owner-ecm@wyvern.aciri.org Wed Feb 7 04:32:07 2001 Received: from wyvern.aciri.org (wyvern.aciri.org [192.150.187.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA27154 for ; Wed, 7 Feb 2001 04:32:05 -0500 (EST) Received: (from majordomo@localhost) by wyvern.aciri.org (8.11.1/8.11.1) id f179TDp68305 for ecm-outgoing; Wed, 7 Feb 2001 01:29:13 -0800 (PST) (envelope-from owner-ecm@smtp.aciri.org) X-Authentication-Warning: wyvern.aciri.org: majordomo set sender to owner-ecm@smtp.aciri.org using -f Received: from mail.iol.ie (mail2.mail.iol.ie [194.125.2.193]) by wyvern.aciri.org (8.11.1/8.11.1) with ESMTP id f179TCX68300 for ; Wed, 7 Feb 2001 01:29:12 -0800 (PST) (envelope-from brennanr@iol.ie) Received: from antioch (e-airlock185.esatclear.ie [194.145.134.185]) by mail.iol.ie Sendmail (v8.9.3) with ESMTP id JAA95072; Wed, 7 Feb 2001 09:28:26 GMT Message-Id: <200102070928.JAA95072@mail.iol.ie> From: "Rob + Helena" To: "Kacheong Poon" Cc: , "Joe Touch" , "Randall R. Stewart" , Subject: Re: SCTP congestion control questions Date: Wed, 7 Feb 2001 09:31:41 -0000 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1162 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ecm@aciri.org Precedence: bulk Content-Transfer-Encoding: 7bit ---------- > From: Kacheong Poon > > > As a relative newcomer to TCP/SCTP congestion control, my (perhaps > > naive) opinion is: > > if the protocol specification is sufficiently loose that a problem like > > bursts > > can occur with poor "implementation decisions" then we should develop > > a minimally intrusive fix to the protocol specification that prevents this > > behaviour for conformant implementations. > > I share your concern as an implementor. But sometimes, IMHO BTW, that > there is a gray area. In this particular case, I believe an implementation > can have several ways to avoid the problem. And any of those ways will > not cause interoperability problem. So should a solution be specified in the > protocol as long as the problem is clearly specified? Or should this be an > implementation choice? OK. However I would suggest that the current SCTP spec should include at least a statement that this is a problem that implementations SHOULD avoid and perhaps an implementation note giving references to research or other IETF work which has possible solutions. > > > This area of protocol stack development is sufficiently obtuse that > > these problems won't become obvious until after deployment (or > > at least some very rigourous testing). > > Again in this particular case, this is a well known problem such that > most, if not all, TCP stacks out there have some form of remedy. So > people implementing SCTP should learn from past experience of TCP. I agree > that there can be other problems which will not be found without rigorous > testing. This is a reason why some people think that a transport protocol > needs several years of real life experience to be called stable... Agreed for the TCP case. For SCTP there is a new generation of implementors/vendors who may not be aware of the full gamut of TCP research. Also the subtle differences between SCTP CC and TCP CC can make it hard to see exactly which research is relevant. This is why I think it would be good to point out the problem in the current SCTP specification. rgds rob From owner-ecm@wyvern.aciri.org Wed Feb 7 08:04:25 2001 Received: from wyvern.aciri.org (wyvern.aciri.org [192.150.187.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA28758 for ; Wed, 7 Feb 2001 08:04:24 -0500 (EST) Received: (from majordomo@localhost) by wyvern.aciri.org (8.11.1/8.11.1) id f17D3sN69875 for ecm-outgoing; Wed, 7 Feb 2001 05:03:54 -0800 (PST) (envelope-from owner-ecm@smtp.aciri.org) X-Authentication-Warning: wyvern.aciri.org: majordomo set sender to owner-ecm@smtp.aciri.org using -f Received: from stewart.chicago.il.us (dsl-64-128-23-213.telocity.com [64.128.23.213]) by wyvern.aciri.org (8.11.1/8.11.1) with ESMTP id f17D3rX69870 for ; Wed, 7 Feb 2001 05:03:53 -0800 (PST) (envelope-from randall@stewart.chicago.il.us) Received: from stewart.chicago.il.us (IDENT:randall@stewart.chicago.il.us [10.1.1.1]) by stewart.chicago.il.us (8.9.3/8.8.7) with ESMTP id HAA15912; Wed, 7 Feb 2001 07:04:22 -0600 Message-ID: <3A8147D6.E620C472@stewart.chicago.il.us> Date: Wed, 07 Feb 2001 07:04:22 -0600 From: "Randall R. Stewart" X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Rob + Helena CC: Joe Touch , mallman@grc.nasa.gov, ecm@aciri.org Subject: Re: SCTP congestion control questions References: <200102070012.AAA72729@mail.iol.ie> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ecm@aciri.org Precedence: bulk Content-Transfer-Encoding: 7bit Rob + Helena wrote: > > Hi all > > ---------- > > From: Randall R. Stewart > > > > Mark/Joe: > > > > One thing to remember on this "burst" is the > > fact that this all supposedly occurs (if I remember > > right from reading Rob's work... Rob help my > > feeble overloaded mind here :->) .. is it > > occurs in one RTT. So, thinking on it, none > > of the reductions may have taken place.. but of > > course you would have to have a very strange occurance > > in that > > > > A) The application would not have more data to clock > > out (as you point out Mark). > > > > and > > > > B) Just has the FR's ACK arrives the application would > > have to have this "Burst" of new data. > > > > These two things seem to me to be unlikely but I don't > > see how other than by having a maxBurst you can gate > > this strange behavior.... > > If anyone is interested I have put a figure illustrating a > SCTP burst after recovery at: > http://www.teltec.dcu.ie/~brennanr/sctp.html > This comes from my simulation model of SCTP running > over a long delay/high bandwidth link with a droptail > gateway with short qs. > > I think that Randal is correct about the non-decay of cwnd > as in the figure we are sending at least 1 pkt per rtt (in fact the > decay is linked to rto rather than rtt directly and these may be > different after a loss). > > On the topic of clocking out more data during recovery: > Note that when FR retransmission occurs there is already > a window of data in flight. This is all out of order so is buffered > at the receiver => a_rwnd is reduced to 0. This means that the > sender is rwnd rather than cwnd limited. When the SACK for > the FR'd pkt arrives the q'd data hasn't yet been sent to the > application so a_rwnd is still 0. No data is in flight so the sender > can then send just one more packet. the SACK for this has a_rwnd > = window size. When the receiver gets this it is no longer rwnd > limited => it can send up to cwnd of data. Cwnd was set to half > of the max window when the FR occured => 1/2 a window of > data is sent. > Rob: I think this is very similar to what Kevin and Sally discuss in "Simulation-based Comparisons of Tahoe,Reno and SACK TCP". In this paper they mention sticking a "maxBurst" on SACK TCP to prevent this behaivor... I think this provides the needed safety value for the obscure places that you will get these results.. In general the normal mechanisms that Mark and I have discussed will address these problems.... If someone else has a better suggestion I would be glad to hear it :) Mark... any ideas? R -- Randall R. Stewart randall@stewart.chicago.il.us or rrs@cisco.com 815-342-5222 (cell) 815-477-2127 (work) From owner-ecm@wyvern.aciri.org Wed Feb 7 20:50:55 2001 Received: from wyvern.aciri.org (wyvern.aciri.org [192.150.187.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA14004 for ; Wed, 7 Feb 2001 20:50:53 -0500 (EST) Received: (from majordomo@localhost) by wyvern.aciri.org (8.11.1/8.11.1) id f181nW276369 for ecm-outgoing; Wed, 7 Feb 2001 17:49:32 -0800 (PST) (envelope-from owner-ecm@smtp.aciri.org) X-Authentication-Warning: wyvern.aciri.org: majordomo set sender to owner-ecm@smtp.aciri.org using -f Received: from gate1.ewag.kamenz.de (netgate-ewag.heitech.net [212.185.189.86] (may be forged)) by wyvern.aciri.org (8.11.1/8.11.1) with SMTP id f181nVX76364 for ; Wed, 7 Feb 2001 17:49:31 -0800 (PST) (envelope-from b4h443@arabia.com) Received: (qmail 16823 invoked from network); 7 Feb 2001 17:56:12 -0000 Received: from 1cust233.tnt12.dfw5.da.uu.net (HELO mail.zuellig.com) (63.44.237.233) by netgate-ewag.heitech.net with SMTP; 7 Feb 2001 17:56:12 -0000 Message-ID: <0000208b6222$00005172$00002cdf@mail.zuellig.com> To: From: b4h443@arabia.com Subject: Brand New E-Mail pager for FR-EE! Date: Wed, 07 Feb 2001 10:51:15 -0600 X-Priority: 3 X-MSMail-Priority: Normal Reply-To: b4h443@arabia.com Sender: owner-ecm@aciri.org Precedence: bulk Brand New E-Mail pager for FREE! No long term contract No activation fee No big prepayment of airtime No credit check PAGING AMERICA is going to give you absolutely Free the Brand new Motorola Accessmate E-Mail display pager. This is the top of the line PCS technology pager made today. This side viewable display pager has a retail value of $189.00and comes with its own e-mail address so you can receive your e-mails as well as alpha-numeric and numeric messages instantly where ever you are. Your new e-mail pager has features like 50,000 character memory, message time stamping, automatic garbled message correction, beeps or vibrates, incandescent backlight, saved message folder, a unique never out of range feature that allows your pager to retrieve messages sent earlier when your pager was out of range or turned completely off. You can also receive weather, news and sports .The Motorola e-mail pager is very small and uses only a single double A battery. All we ask before we ship you your Free pager is for you to allow us to provide the airtime for you. There is no long term contract or credit check. Airtime is month to month and can be cancelled at any time. This pager will comes pre-programmed with its own e-mail address as well as a local telephone number to receive numeric pages. This pager comes with a complete 30 day money back guarantee, if after receiving this pager you're not completely happy, send it back and receive a full refund. For immediate delivery call Paging America at toll free at 877-699-8545 Brand New E-Mail pager for FREE! From owner-ecm@wyvern.aciri.org Fri Feb 23 18:19:14 2001 Received: from wyvern.aciri.org (wyvern.aciri.org [192.150.187.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26433 for ; Fri, 23 Feb 2001 18:19:11 -0500 (EST) Received: (from majordomo@localhost) by wyvern.aciri.org (8.11.1/8.11.1) id f1NNFVV13196 for ecm-outgoing; Fri, 23 Feb 2001 15:15:31 -0800 (PST) (envelope-from owner-ecm@smtp.aciri.org) X-Authentication-Warning: wyvern.aciri.org: majordomo set sender to owner-ecm@smtp.aciri.org using -f Received: from mg2.jjcn.ne.jp (mg2.jjcn.ne.jp [210.81.64.156]) by wyvern.aciri.org (8.11.1/8.11.1) with SMTP id f1NNFPP13191 for ; Fri, 23 Feb 2001 15:15:26 -0800 (PST) (envelope-from bigjoe@japan.com) Received: (qmail 9372 invoked by uid 0); 7 Feb 2001 20:32:28 -0000 Received: from 1cust240.tnt12.dfw5.da.uu.net (HELO 1Cust240.tnt12.dfw5.da.uu.net??63.44.237.240?) (63.44.237.240) by mg2.jjcn.ne.jp with SMTP; 7 Feb 2001 20:32:28 -0000 Received: from ns.ispinc.net by 1Cust240.tnt12.dfw5.da.uu.net with ESMTP; Wed, 07 Feb 2001 14:31:32 -0600 Message-ID: <00001124262b$00003410$00005555@ns.ispinc.net> To: From: bigjoe@japan.com Subject: Brand New E-Mail pager for FR-EE! 21845 Date: Wed, 07 Feb 2001 14:31:24 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Reply-To: bigjoe@japan.com Sender: owner-ecm@aciri.org Precedence: bulk Content-Transfer-Encoding: 7bit Accessmate E-Mail display pager. This is the top of the line PCS technology pager made today. This side viewable display pager has a retail value of $189.00and comes with its own e-mail address so you can receive your e-mails as well as alpha-numeric and numeric messages instantly where ever you are. Your new e-mail pager has features like 50,000 character memory, message time stamping, automatic garbled message correction, beeps or vibrates, incandescent backlight, saved message folder, a unique never out of range feature that allows your pager to retrieve messages sent earlier when your pager was out of range or turned completely off. You can also receive weather, news and sports .The Motorola e-mail pager is very small and uses only a single double A battery. All we ask before we ship you your Free pager is for you to allow us to provide the airtime for you. There is no long term contract or credit check. Airtime is month to month and can be cancelled at any time. This pager will comes pre-programmed with its own e-mail address as well as a local telephone number to receive numeric pages. This pager comes with a complete 30 day money back guarantee, if after receiving this pager you're not completely happy, send it back and receive a full refund. For immediate delivery call Paging America at toll free at 877-699-8546 Brand New E-Mail pager for FREE! No long term contract No activation fee No big prepayment of airtime No credit check PAGING AMERICA is going to give you absolutely Free the Brand new Motorola