From mailnull@www1.ietf.org Mon May 5 12:52:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07704 for ; Mon, 5 May 2003 12:52:56 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h45H11L16778 for tsvwg-archive@odin.ietf.org; Mon, 5 May 2003 13:01:01 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h45GuX816496; Mon, 5 May 2003 12:56:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h45GsP816437 for ; Mon, 5 May 2003 12:54:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07423 for ; Mon, 5 May 2003 12:45:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Cj89-0006xT-00 for tsvwg@ietf.org; Mon, 05 May 2003 12:47:57 -0400 Received: from web41805.mail.yahoo.com ([66.218.93.139]) by ietf-mx with smtp (Exim 4.12) id 19Cj83-0006xB-00 for tsvwg@ietf.org; Mon, 05 May 2003 12:47:51 -0400 Message-ID: <20030505164734.55774.qmail@web41805.mail.yahoo.com> Received: from [65.213.193.49] by web41805.mail.yahoo.com via HTTP; Mon, 05 May 2003 09:47:34 PDT Date: Mon, 5 May 2003 09:47:34 -0700 (PDT) From: CAITR Reply-To: info@caitr.org To: tsvwg@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-125212143-1052153254=:51212" Subject: [Tsvwg] Internetworking 2003: Call for Participation Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , --0-125212143-1052153254=:51212 Content-Type: text/plain; charset=us-ascii Internetworking 2003 International Conference Hilton San Jose & Towers Hotel, California June 22-June 24, 2003 http://www.caitr.org/internetworking03/index.htm You are cordially invited to attend the Internetworking 2003 International Conference to be held in San Jose, California, June 22-24, 2003. The 3-day event consists of two-days of highly technical sessions, preceded by four technical tutorials.Registration for the conference is underway. Please visit http://www.caitr.org/internetworking03/registration.htm and follow instructions for registration. The early registration discounts are extremely attractive and are valid till June 1, 2003.Important Dates: --------------------- - Early Registration Rates Cut-Off Date: Sept 30 - Tutorials: Oct 27, 1:00-6:00 pm - Conference sessions: October 28-29 8:30am-6:00pmProgram: ------------- (visit http://www.caitr.org/internetworking03/program.htm for abstracts and speaker details)Sunday June 22 Tutorial-1: MPLS VPNs Tutorial-2: IPv6 Tutorial-3: Mobile Wireless Internet Architecture and Protocols Tutorial-4: Voice over Packet Monday June 23 Welcome and Keynote Session: Network Technology Trends - Forwarding Element and Control Separation - Evolution of Inter-Domain Routing - Network Processing Building Blocks: Enabling the Routers of the Future Session: Network Architecture - An architecture for IPv6 VPNs and IPv6 transport over MPLS/GMPLS multiservice backbones IPv6 - A new routing architecture: Atomised Routing - Internetworking MPLS Layer 2 Transport with an IP Services Network Session: Storage Area Networks - Storage as a Network Node - Object-Based Storage - Design, Implementation, and Performance Analysis of the iSCSI Protocol for SCSI over TCP/IP - SANs Considerations Session: Mobile & Wireless Networks - CertBU: Certificate-based Techniques for Securing Mobile IPv6 Binding Updates IPv6 - Challenges and Roadmap of UMTS Network Deployment - Inter-working Mobile IPv6 with IP Multimedia Subsystem in UMTS - Mobile Authentication and QoS - Mobile Handoff Technologies Tuesday June 24 Session: Inter-Domain Routing - Optimizing Route Convergence - Traceroute and BGP AS Path Incongruities - Domain Constrained Multicast: A New Approach for IP Multicast Routing Session: Applications & Services - Securing the Web with Next Generation Encryption Technologies - Impact of the live radio on the Internet, and the real-time streaming audio, in the ComUNITY cable system from Com21 - A novel EAC semantic for the RTSP protocol - Towards an end-to-end architecture integrating new Transport and IP services in a DiffServ Internet Session: Network Management & Planning - Pseudowire OAM: A Mandatory Yet Often Overlooked Feature - A Multicommodity Flow Formulation for the MPLS Layout Design: Reduced Complexity Layout and Minimum Relayout Probems - Design Of Fast Fault Restoration System For WDM Networks - Cross-domain multimedia service provisioning, the EVOLUTE solution Session: QoS Based Routing - QoS Routing in Networks with Non-Deterministic Information - Active Dynamic Routing - QoS routing for Differentiated Services: simulations and prototype experiments - Probabilistic routing for QoS improvement in GPS networks - Fluid flow network modeling for hop-by-hop feedback control design and analysis We look forward to seeing you at the Conference. Regards, Conference Technical Co-chairs: - Dr. Maurice Gagnaire, ENST, France - Daniel Awduche Technical Program Committee of the Internetworking 2003 Conference: - Roberto Sabella, Erisson - Dr. Moshe Zukerman, Univ. of Melbourne - Nada Golmie, NIST - Dr. Guy Pujolle, LIP6, France - Dr. Samir Tohme, ENST, France - Stefano Trumpy, Italian National Research Council - Dr. Ibrahim Habib, City Univ. of NY - Dr. Marc Lobelle, UCL University, Belgium - Dr. Parviz Yegani, Cisco Systems - Dr. G.S. Kuo - Dr. Abbas Jamalipour, Univ. of Sydney - Dr. Hussein Mouftah, Univ. of Ottawa - James Kempf - Elizabeth Rodriguez - Dr. Ferit Yegenoglu, Isocore - Dr. Ali Zadeh, George Mason University - Dr. Tony Przygienda, Xebeo - Ran Canetti, IBM --0-125212143-1052153254=:51212 Content-Type: text/html; charset=us-ascii

     Internetworking 2003 International Conference
     Hilton San Jose & Towers Hotel, California
              June 22-June 24, 2003
    http://www.caitr.org/internetworking03/index.htm
  
You are cordially invited to attend the Internetworking 2003 International Conference to be held in San Jose, California, June 22-24, 2003. The 3-day event consists of two-days of highly technical sessions, preceded by four technical tutorials.
Registration for the conference is underway. Please visit http://www.caitr.org/internetworking03/registration.htm and follow instructions for registration. The early registration discounts are extremely attractive and are valid till June 1, 2003.
Important Dates:
---------------------
- Early Registration Rates Cut-Off Date: Sept 30
- Tutorials: Oct 27, 1:00-6:00 pm
- Conference sessions: October 28-29 8:30am-6:00pm
Program:
-------------
(visit http://www.caitr.org/internetworking03/program.htm for abstracts and speaker details)
Sunday June 22
    Tutorial-1: MPLS VPNs 
    Tutorial-2: IPv6 
    Tutorial-3: Mobile Wireless Internet Architecture and Protocols
    Tutorial-4: Voice over Packet 
Monday June 23
    Welcome and Keynote 
    Session: Network Technology Trends
      - Forwarding Element and Control Separation
      - Evolution of Inter-Domain Routing
      - Network Processing Building Blocks: Enabling the Routers of the Future
    Session: Network Architecture
      - An architecture for IPv6 VPNs and IPv6 transport over MPLS/GMPLS multiservice backbones IPv6
      - A new routing architecture: Atomised Routing
      - Internetworking MPLS Layer 2 Transport with an IP Services Network
    Session: Storage Area Networks
      - Storage as a Network Node
      - Object-Based Storage
      - Design, Implementation, and ! Performance Analysis of the iSCSI Protocol for SCSI over TCP/IP
      - SANs Considerations
 
    Session: Mobile & Wireless Networks
      - CertBU: Certificate-based Techniques for Securing Mobile IPv6 Binding Updates IPv6
      - Challenges and Roadmap of UMTS Network Deployment
      - Inter-working Mobile IPv6 with IP Multimedia Subsystem in UMTS 
      - Mobile Authentication and QoS 
      - Mobile Handoff Technologies 
Tuesday June 24
    Session: Inter-Domain Routing
      - Optimizing Route Convergence
      - Traceroute and BGP AS Path Incongruities 
      - Domain Constrained Multicast: A New Approach for IP Multicast Routing
 
    Session: Applications & Services
     -  Securing the Web with Next Generation Encryption Technologies
     - Impact of the live radio on the Internet, and the real-time streaming audio, in the ComUNITY cable system from Com21
     - A novel EAC semantic for the RTSP protocol
     - Towards an end-to-end architecture integrating new Transport and IP services in a DiffServ Internet
 
    Session: Network Management & Planning
     -  Pseudowire OAM: A Mandatory Ye! t Often Overlooked Feature 
     - A Multicommodity Flow Formulation for the MPLS Layout Design: Reduced Complexity Layout and Minimum Relayout Probems
     - Design Of Fast Fault Restoration System For WDM Networks
     - Cross-domain multimedia service provisioning, the EVOLUTE solution
 
    Session: QoS Based Routing
     - QoS Routing in Networks with Non-Deterministic Information
     - Active Dynamic Routing
     - QoS routing for Differentiated Services: simulations and prototype experiments
     - Probabilistic routing for QoS improvement in GPS networks
     - Fluid flow network modeling for hop-by-hop feedback control design and analysis
 
We look forward to seeing you at the Conference.
Regards,
 Conference Technical Co-chai! rs:
 - Dr. Maurice Gagnaire, ENST, France
 - Daniel Awduche
 Technical Program Committee of the Internetworking 2003 Conference:
 - Roberto Sabella, Erisson
 - Dr. Moshe Zukerman, Univ. of Melbourne
 - Nada Golmie, NIST
 - Dr. Guy Pujolle, LIP6, France
 - Dr. Samir Tohme, ENST, France
 - Stefano Trumpy, Italian National Research Council
 - Dr. Ibrahim Habib, City Univ. of NY
 - Dr. Marc Lobelle, UCL University, Belgium
 - Dr. Parviz Yegani, Cisco Systems
 - Dr. G.S. Kuo
 - Dr. Abbas Jamalipour, Univ. of Sydney
 - Dr. Hussein Mouftah, Univ. of Ottawa
 - James Kempf
 - Elizabeth Rodriguez
 - Dr. Ferit Yegenoglu, Isocore
 - Dr. Ali Zadeh, George Mason University
 - Dr. Tony Przygienda, Xebeo
 - Ran Canetti, IBM

 
--0-125212143-1052153254=:51212-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon May 5 14:48:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11095 for ; Mon, 5 May 2003 14:48:09 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h45IuFI25468 for tsvwg-archive@odin.ietf.org; Mon, 5 May 2003 14:56:15 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h45IqO825314; Mon, 5 May 2003 14:52:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h45InI825201 for ; Mon, 5 May 2003 14:49:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10816 for ; Mon, 5 May 2003 14:39:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CkuE-0007bd-00 for tsvwg@ietf.org; Mon, 05 May 2003 14:41:42 -0400 Received: from gw.openss7.com ([142.179.199.224] ident=[IJkcNDLESGLukyGfY/okchp1tTA0huMW]) by ietf-mx with esmtp (Exim 4.12) id 19Cku3-0007bT-00 for tsvwg@ietf.org; Mon, 05 May 2003 14:41:31 -0400 Received: from ns.pigworks.openss7.net (IDENT:GDSO4xZpksmYibvwdtOBgK5dMrZ4fffK@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h45IYQl06965; Mon, 5 May 2003 12:34:26 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h45IYOS27183; Mon, 5 May 2003 12:34:24 -0600 Date: Mon, 5 May 2003 12:34:24 -0600 From: "Brian F. G. Bidulock" To: "Randall Stewart (cisco)" , tsvwg@ietf.org Cc: "Sellar, Ronnie" , "Sctp-Impl (E-mail)" , "Phillip T. Conrad" , Qiaobing Xie , =?iso-8859-1?Q?Michael_T=FCxen?= , "Michael A. Ramalho" Message-ID: <20030505123424.B23984@openss7.org> Reply-To: bidulock@openss7.org References: <797470E884C6D611B7A500B0D0AA56D04426F1@batistuta.spider.com> <3EB6838D.1040504@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3EB6838D.1040504@cisco.com>; from rrs@cisco.com on Mon, May 05, 2003 at 10:30:22AM -0500 Organization: http://www.openss7.org/ Dsn-Notification-To: X-MIME-Autoconverted: from 8bit to quoted-printable by gw.openss7.com id h45IYQl06965 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h45Ip8825257 Subject: [Tsvwg] Re: PR-SCTP question. Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Randall, If the FWD-TSN is treated in the same fashion as DATA is in the base protocol with regard to the sending of SACK, in this case a SACK would already be required by the base protocol would it not? So I don't think that there is a need for an alteration in SACK processing. IHO the problem appears to be (as you allude) that for a normal DATA transmission there is a retransmit timer running whereas for FWD-TSN there is not. During normal data transmission during the association, this is not problematic because of the rules for sending subsequent FWD-TSN in receipt of SACK. It is only in this case where there is no further data to send. As this only appears to be a problem in this one situation (not subsequent DATA to send and no SACKs forthcoming), it might be possible to handle this with a SHUTDOWN rule such as follows: Whenever the PR-SCTP sender enters the SHUTDOWN-PENDING state, and there are only TSNs marked dropped for retransmission (for which FWD-TSNs have been sent) a SHUTDOWN chunk is sent and the sender enters the SHUTDOWN-SENT state. (The same for SHUTDOWN-RECEIVED and SHUTDOWN-ACK-SENT states.) Whenever the PR-SCTP receiver receives a SHUTDOWN or SHUTDOWN-ACK and there are gaps in its received TSN sequence (messages awaiting reordering before delivery to the user), it will treat the SHUTDOWN or SHUTDOWN-ACK though it were a forward TSN for all missing data chunks. The trick here is to not delay the SHUTDOWN (or SHUTDOWN-ACK) chunk being sent waiting for acknowledgement of dropped TSNs but to send it anyways with the knowledge that the receiver can imply any missing TSNs as having been dropped. I think this would better meet the intent of PR-SCTP (and in particular timed-reliability) as it does not rely on a timer to arrive at the implication of a missed FWD-TSN. The receipt of a SHUTDOWN or SHUTDOWN-ACK can be treated as an implied FWD-TSN for all outstanding data. Under the base protocol, what happens if a sender sends a SHUTDOWN chunk *before* all its sent data is acknowledged? I think an implementation could either complete the shutdown and discard data awaiting reordering, or ABORT the association. For PR-SCTP, receiving SHUTDOWN early could be construed as cause to mark as dropped all outstanding data, and move the cummulative ack point to the "highest" received TSN and complete the SHUTDOWN procedure. Does that make sense? So effectively the rules would be that a SHUTDOWN or SHUTDOWN-ACK should not be delayed in the SHUTDOWN-PENDING or SHUTDOWN-RECEIVED states solely on the basis of unacknowledged but "dropped" TSNs, and that a received SHUTDOWN or SHUTDOWN-ACK chunk that is otherwise valid should be construed by the receiver to have the same effect as a FWD-TSN dropping all outstanding TSNs. Is that simpler than a timer? --brian Whenever the receiver receives On Mon, 05 May 2003, Randall Stewart (cisco) wrote: > Ronnie: > > Nope, I don't think you are missing anything. I have been testing the > internal Cisco-IOS implementation of PR-SCTP against the KAME stack > and have reached the same conclusion. I think we need to require that the > receiver of a FWD-TSN send a SACK in reponse to this. Otherwise > you have this deadlock scenario.... I have made the KAME stack > send the SACK.. but this then begs another question... > > If the SACK in the return path was lost (I am testing at times with > error rates set to 20%... so that happens a lot).. what do we do? > > It almost sounds like we need not only to require a FWD-TSN get > a SACK in response.. but that the sender of the FWD-TSN, if no > other data is being sent, start a timer to retransmit the FWD-TSN > if no SACK is received.. not sure if I worded that clear but I think > it will be needed... > > Co-authors.. what do you-all think? > > R > > > Sellar, Ronnie wrote: > > >Hi, > > > >We have just started looking at PR-SCTP with a view to having a prototype > >implementation ready for the next Interop in Delaware and have come up with > >a question regarding the FORWARD-TSN chunk and how it could affect > >association termination. > > > >Consider the following example. Endpoint A has an association with endpoint > >B in which all the data it sends is ordered and marked as 'unreliable' for > >whatever reason. Endpoint A has now sent all the data it wants to send to B > >but can't yet close the association because B has not yet acknowledged one > >of the TSNs. Lets say that it has transmitted TSNs 1-100 but has not yet > >received an acknowledgement of TSN 97 since B has not yet received that TSN. > > > >In this situation A cannot yet send the SHUTDOWN since not all data is acked > >and B has three chunks it cannot deliver to it's user (98, 99 and 100) since > >it has not received 97. When A receives the last SACK it decides that it no > >longer wants to retransmit chunk 97 and so issues a FORWARD-TSN chunk to > >move the cumulative ack TSN on to 100. How does A know that B received the > >FORWARD-TSN chunk ? There is no more data to send so B will not be sending > >any more SACKs. If B sends no more SACKs A's cumulative ack TSN will not > >advance and so he will not be able to send the SHUTDOWN chunk. > > > >In B's case when he receives the FORWARD-TSN he will be happy, deliver > >98-100 to the user and move his cumulative TSN forward. But he is not > >required to send a SACK to tell A he has done so. Are we now in a stalemate > >situation ? > > > >Also consider the case where B never receives the FORWARD-TSN. He is now > >stuck with 98-100 in his buffers which he cannot deliver since he doesn't > >know that 97 is not coming. Have we reached a similar stalemate ? > > > >Perhaps I'm missing something, but I do think there seems to be a problem if > >a FORWARD-TSN chunk is the last chunk to be transmitted on an association. > >Please feel free to correct me if I'm wrong. > > > >Cheers > > > >Ronnie > > > >--- > >Ronnie Sellar Artesyn Communications Products > >Tel: +44 131 475 7015 Suite 4, 2 Anderson Place > >Fax: +44 131 475 7001 Edinburgh EH6 5NP > >mailto:ronnie@artesyncp.com http://www.artesyncp.com > > > > > > > > > -- > Randall R. Stewart > ITD > Cisco Systems Inc. > rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) > -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon May 5 15:23:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13295 for ; Mon, 5 May 2003 15:23:29 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h45JVZR27856 for tsvwg-archive@odin.ietf.org; Mon, 5 May 2003 15:31:35 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h45JRv827689; Mon, 5 May 2003 15:27:57 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h45JQH827631 for ; Mon, 5 May 2003 15:26:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13086; Mon, 5 May 2003 15:17:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ClV2-00001j-00; Mon, 05 May 2003 15:19:44 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by ietf-mx with esmtp (Exim 4.12) id 19ClUw-00001R-00; Mon, 05 May 2003 15:19:38 -0400 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h45Ijfua001658; Mon, 5 May 2003 11:45:42 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AGV27516; Mon, 5 May 2003 11:45:39 -0700 (PDT) Message-ID: <3EB6B151.3040506@cisco.com> Date: Mon, 05 May 2003 13:45:37 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3) Gecko/20030502 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org CC: tsvwg@ietf.org, "Sellar, Ronnie" , "Sctp-Impl (E-mail)" , "Phillip T. Conrad" , Qiaobing Xie , =?ISO-8859-1?Q?Michael_T=FCxen?= , "Michael A. Ramalho" References: <797470E884C6D611B7A500B0D0AA56D04426F1@batistuta.spider.com> <3EB6838D.1040504@cisco.com> <20030505123424.B23984@openss7.org> In-Reply-To: <20030505123424.B23984@openss7.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Tsvwg] Re: PR-SCTP question. Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Brian: Seems like a much better solution than having a timer.. so we end up with: 1) A note in PR-SCTP about the SHUTDOWN cases as you mention. 2) A note in PR-SCTP regarding SACK's aka a FWD-TSN MUST be treated as a DATA chunk in regard to sending SACK's ( I think this is needed since there is no mention to it in the document currently). R Brian F. G. Bidulock wrote: >Randall, > >If the FWD-TSN is treated in the same fashion as DATA is in the >base protocol with regard to the sending of SACK, in this case a >SACK would already be required by the base protocol would it >not? So I don't think that there is a need for an alteration in >SACK processing. IHO the problem appears to be (as you allude) >that for a normal DATA transmission there is a retransmit timer >running whereas for FWD-TSN there is not. During normal data >transmission during the association, this is not problematic >because of the rules for sending subsequent FWD-TSN in receipt >of SACK. It is only in this case where there is no further data >to send. > >As this only appears to be a problem in this one situation (not >subsequent DATA to send and no SACKs forthcoming), it might be >possible to handle this with a SHUTDOWN rule such as follows: > >Whenever the PR-SCTP sender enters the SHUTDOWN-PENDING state, >and there are only TSNs marked dropped for retransmission (for >which FWD-TSNs have been sent) a SHUTDOWN chunk is sent and the >sender enters the SHUTDOWN-SENT state. (The same for >SHUTDOWN-RECEIVED and SHUTDOWN-ACK-SENT states.) > >Whenever the PR-SCTP receiver receives a SHUTDOWN or >SHUTDOWN-ACK and there are gaps in its received TSN sequence >(messages awaiting reordering before delivery to the user), it >will treat the SHUTDOWN or SHUTDOWN-ACK though it were a forward >TSN for all missing data chunks. > >The trick here is to not delay the SHUTDOWN (or SHUTDOWN-ACK) >chunk being sent waiting for acknowledgement of dropped TSNs >but to send it anyways with the knowledge that the receiver can >imply any missing TSNs as having been dropped. > >I think this would better meet the intent of PR-SCTP (and in >particular timed-reliability) as it does not rely on a timer to >arrive at the implication of a missed FWD-TSN. The receipt of a >SHUTDOWN or SHUTDOWN-ACK can be treated as an implied FWD-TSN >for all outstanding data. > >Under the base protocol, what happens if a sender sends a >SHUTDOWN chunk *before* all its sent data is acknowledged? I >think an implementation could either complete the shutdown and >discard data awaiting reordering, or ABORT the association. For >PR-SCTP, receiving SHUTDOWN early could be construed as cause to >mark as dropped all outstanding data, and move the cummulative >ack point to the "highest" received TSN and complete the >SHUTDOWN procedure. > >Does that make sense? > >So effectively the rules would be that a SHUTDOWN or >SHUTDOWN-ACK should not be delayed in the SHUTDOWN-PENDING or >SHUTDOWN-RECEIVED states solely on the basis of unacknowledged >but "dropped" TSNs, and that a received SHUTDOWN or SHUTDOWN-ACK >chunk that is otherwise valid should be construed by the >receiver to have the same effect as a FWD-TSN dropping all >outstanding TSNs. > >Is that simpler than a timer? > >--brian > > >Whenever the receiver receives > > >On Mon, 05 May 2003, Randall Stewart (cisco) wrote: > > > >>Ronnie: >> >>Nope, I don't think you are missing anything. I have been testing the >>internal Cisco-IOS implementation of PR-SCTP against the KAME stack >>and have reached the same conclusion. I think we need to require that the >>receiver of a FWD-TSN send a SACK in reponse to this. Otherwise >>you have this deadlock scenario.... I have made the KAME stack >>send the SACK.. but this then begs another question... >> >>If the SACK in the return path was lost (I am testing at times with >>error rates set to 20%... so that happens a lot).. what do we do? >> >>It almost sounds like we need not only to require a FWD-TSN get >>a SACK in response.. but that the sender of the FWD-TSN, if no >>other data is being sent, start a timer to retransmit the FWD-TSN >>if no SACK is received.. not sure if I worded that clear but I think >>it will be needed... >> >>Co-authors.. what do you-all think? >> >>R >> >> >>Sellar, Ronnie wrote: >> >> >> >>>Hi, >>> >>>We have just started looking at PR-SCTP with a view to having a prototype >>>implementation ready for the next Interop in Delaware and have come up with >>>a question regarding the FORWARD-TSN chunk and how it could affect >>>association termination. >>> >>>Consider the following example. Endpoint A has an association with endpoint >>>B in which all the data it sends is ordered and marked as 'unreliable' for >>>whatever reason. Endpoint A has now sent all the data it wants to send to B >>>but can't yet close the association because B has not yet acknowledged one >>>of the TSNs. Lets say that it has transmitted TSNs 1-100 but has not yet >>>received an acknowledgement of TSN 97 since B has not yet received that TSN. >>> >>>In this situation A cannot yet send the SHUTDOWN since not all data is acked >>>and B has three chunks it cannot deliver to it's user (98, 99 and 100) since >>>it has not received 97. When A receives the last SACK it decides that it no >>>longer wants to retransmit chunk 97 and so issues a FORWARD-TSN chunk to >>>move the cumulative ack TSN on to 100. How does A know that B received the >>>FORWARD-TSN chunk ? There is no more data to send so B will not be sending >>>any more SACKs. If B sends no more SACKs A's cumulative ack TSN will not >>>advance and so he will not be able to send the SHUTDOWN chunk. >>> >>>In B's case when he receives the FORWARD-TSN he will be happy, deliver >>>98-100 to the user and move his cumulative TSN forward. But he is not >>>required to send a SACK to tell A he has done so. Are we now in a stalemate >>>situation ? >>> >>>Also consider the case where B never receives the FORWARD-TSN. He is now >>>stuck with 98-100 in his buffers which he cannot deliver since he doesn't >>>know that 97 is not coming. Have we reached a similar stalemate ? >>> >>>Perhaps I'm missing something, but I do think there seems to be a problem if >>>a FORWARD-TSN chunk is the last chunk to be transmitted on an association. >>>Please feel free to correct me if I'm wrong. >>> >>>Cheers >>> >>>Ronnie >>> >>>--- >>>Ronnie Sellar Artesyn Communications Products >>>Tel: +44 131 475 7015 Suite 4, 2 Anderson Place >>>Fax: +44 131 475 7001 Edinburgh EH6 5NP >>>mailto:ronnie@artesyncp.com http://www.artesyncp.com >>> >>> >>> >>> >>> >>-- >>Randall R. Stewart >>ITD >>Cisco Systems Inc. >>rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) >> >> >> > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon May 5 16:00:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14118 for ; Mon, 5 May 2003 16:00:27 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h45K8Zf31067 for tsvwg-archive@odin.ietf.org; Mon, 5 May 2003 16:08:35 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h45K2R830019; Mon, 5 May 2003 16:02:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h45JqM829611 for ; Mon, 5 May 2003 15:52:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13804 for ; Mon, 5 May 2003 15:43:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CluI-0000Aj-00 for tsvwg@ietf.org; Mon, 05 May 2003 15:45:50 -0400 Received: from gw.openss7.com ([142.179.199.224] ident=[Ft3YBS/Zwcm2BVOk30Ngyks8OecU+UM6]) by ietf-mx with esmtp (Exim 4.12) id 19Clu7-0000Aa-00 for tsvwg@ietf.org; Mon, 05 May 2003 15:45:39 -0400 Received: from ns.pigworks.openss7.net (IDENT:SST6FLwLsJtVvoxMsN8pZc3IKwiY2+Z7@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h45JdVl08030; Mon, 5 May 2003 13:39:31 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h45JdUa28551; Mon, 5 May 2003 13:39:30 -0600 Date: Mon, 5 May 2003 13:39:30 -0600 From: "Brian F. G. Bidulock" To: "Randall Stewart (cisco)" Cc: tsvwg@ietf.org, "Sellar, Ronnie" , "Sctp-Impl (E-mail)" , "Phillip T. Conrad" , Qiaobing Xie , =?iso-8859-1?Q?Michael_T=FCxen?= , "Michael A. Ramalho" Message-ID: <20030505133930.C23337@openss7.org> Reply-To: bidulock@openss7.org References: <797470E884C6D611B7A500B0D0AA56D04426F1@batistuta.spider.com> <3EB6838D.1040504@cisco.com> <20030505123424.B23984@openss7.org> <3EB6B151.3040506@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3EB6B151.3040506@cisco.com>; from rrs@cisco.com on Mon, May 05, 2003 at 01:45:37PM -0500 Organization: http://www.openss7.org/ Dsn-Notification-To: X-MIME-Autoconverted: from 8bit to quoted-printable by gw.openss7.com id h45JdVl08030 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h45Jrg829659 Subject: [Tsvwg] Re: PR-SCTP question. Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Randall, It would also be interesting to test this solution in Delaware. --brian On Mon, 05 May 2003, Randall Stewart (cisco) wrote: > Brian: > > Seems like a much better solution than having a timer.. > > so we end up with: > > 1) A note in PR-SCTP about the SHUTDOWN cases as you mention. > > 2) A note in PR-SCTP regarding SACK's aka a FWD-TSN MUST be > treated as a DATA chunk in regard to sending SACK's ( I think > this is needed since there is no mention to it in the document > currently). > > R > > > Brian F. G. Bidulock wrote: > > >Randall, > > > >If the FWD-TSN is treated in the same fashion as DATA is in the > >base protocol with regard to the sending of SACK, in this case a > >SACK would already be required by the base protocol would it > >not? So I don't think that there is a need for an alteration in > >SACK processing. IHO the problem appears to be (as you allude) > >that for a normal DATA transmission there is a retransmit timer > >running whereas for FWD-TSN there is not. During normal data > >transmission during the association, this is not problematic > >because of the rules for sending subsequent FWD-TSN in receipt > >of SACK. It is only in this case where there is no further data > >to send. > > > >As this only appears to be a problem in this one situation (not > >subsequent DATA to send and no SACKs forthcoming), it might be > >possible to handle this with a SHUTDOWN rule such as follows: > > > >Whenever the PR-SCTP sender enters the SHUTDOWN-PENDING state, > >and there are only TSNs marked dropped for retransmission (for > >which FWD-TSNs have been sent) a SHUTDOWN chunk is sent and the > >sender enters the SHUTDOWN-SENT state. (The same for > >SHUTDOWN-RECEIVED and SHUTDOWN-ACK-SENT states.) > > > >Whenever the PR-SCTP receiver receives a SHUTDOWN or > >SHUTDOWN-ACK and there are gaps in its received TSN sequence > >(messages awaiting reordering before delivery to the user), it > >will treat the SHUTDOWN or SHUTDOWN-ACK though it were a forward > >TSN for all missing data chunks. > > > >The trick here is to not delay the SHUTDOWN (or SHUTDOWN-ACK) > >chunk being sent waiting for acknowledgement of dropped TSNs > >but to send it anyways with the knowledge that the receiver can > >imply any missing TSNs as having been dropped. > > > >I think this would better meet the intent of PR-SCTP (and in > >particular timed-reliability) as it does not rely on a timer to > >arrive at the implication of a missed FWD-TSN. The receipt of a > >SHUTDOWN or SHUTDOWN-ACK can be treated as an implied FWD-TSN > >for all outstanding data. > > > >Under the base protocol, what happens if a sender sends a > >SHUTDOWN chunk *before* all its sent data is acknowledged? I > >think an implementation could either complete the shutdown and > >discard data awaiting reordering, or ABORT the association. For > >PR-SCTP, receiving SHUTDOWN early could be construed as cause to > >mark as dropped all outstanding data, and move the cummulative > >ack point to the "highest" received TSN and complete the > >SHUTDOWN procedure. > > > >Does that make sense? > > > >So effectively the rules would be that a SHUTDOWN or > >SHUTDOWN-ACK should not be delayed in the SHUTDOWN-PENDING or > >SHUTDOWN-RECEIVED states solely on the basis of unacknowledged > >but "dropped" TSNs, and that a received SHUTDOWN or SHUTDOWN-ACK > >chunk that is otherwise valid should be construed by the > >receiver to have the same effect as a FWD-TSN dropping all > >outstanding TSNs. > > > >Is that simpler than a timer? > > > >--brian > > > > > >Whenever the receiver receives > > > > > >On Mon, 05 May 2003, Randall Stewart (cisco) wrote: > > > > > > > >>Ronnie: > >> > >>Nope, I don't think you are missing anything. I have been testing the > >>internal Cisco-IOS implementation of PR-SCTP against the KAME stack > >>and have reached the same conclusion. I think we need to require that the > >>receiver of a FWD-TSN send a SACK in reponse to this. Otherwise > >>you have this deadlock scenario.... I have made the KAME stack > >>send the SACK.. but this then begs another question... > >> > >>If the SACK in the return path was lost (I am testing at times with > >>error rates set to 20%... so that happens a lot).. what do we do? > >> > >>It almost sounds like we need not only to require a FWD-TSN get > >>a SACK in response.. but that the sender of the FWD-TSN, if no > >>other data is being sent, start a timer to retransmit the FWD-TSN > >>if no SACK is received.. not sure if I worded that clear but I think > >>it will be needed... > >> > >>Co-authors.. what do you-all think? > >> > >>R > >> > >> > >>Sellar, Ronnie wrote: > >> > >> > >> > >>>Hi, > >>> > >>>We have just started looking at PR-SCTP with a view to having a prototype > >>>implementation ready for the next Interop in Delaware and have come up with > >>>a question regarding the FORWARD-TSN chunk and how it could affect > >>>association termination. > >>> > >>>Consider the following example. Endpoint A has an association with endpoint > >>>B in which all the data it sends is ordered and marked as 'unreliable' for > >>>whatever reason. Endpoint A has now sent all the data it wants to send to B > >>>but can't yet close the association because B has not yet acknowledged one > >>>of the TSNs. Lets say that it has transmitted TSNs 1-100 but has not yet > >>>received an acknowledgement of TSN 97 since B has not yet received that TSN. > >>> > >>>In this situation A cannot yet send the SHUTDOWN since not all data is acked > >>>and B has three chunks it cannot deliver to it's user (98, 99 and 100) since > >>>it has not received 97. When A receives the last SACK it decides that it no > >>>longer wants to retransmit chunk 97 and so issues a FORWARD-TSN chunk to > >>>move the cumulative ack TSN on to 100. How does A know that B received the > >>>FORWARD-TSN chunk ? There is no more data to send so B will not be sending > >>>any more SACKs. If B sends no more SACKs A's cumulative ack TSN will not > >>>advance and so he will not be able to send the SHUTDOWN chunk. > >>> > >>>In B's case when he receives the FORWARD-TSN he will be happy, deliver > >>>98-100 to the user and move his cumulative TSN forward. But he is not > >>>required to send a SACK to tell A he has done so. Are we now in a stalemate > >>>situation ? > >>> > >>>Also consider the case where B never receives the FORWARD-TSN. He is now > >>>stuck with 98-100 in his buffers which he cannot deliver since he doesn't > >>>know that 97 is not coming. Have we reached a similar stalemate ? > >>> > >>>Perhaps I'm missing something, but I do think there seems to be a problem if > >>>a FORWARD-TSN chunk is the last chunk to be transmitted on an association. > >>>Please feel free to correct me if I'm wrong. > >>> > >>>Cheers > >>> > >>>Ronnie > >>> > >>>--- > >>>Ronnie Sellar Artesyn Communications Products > >>>Tel: +44 131 475 7015 Suite 4, 2 Anderson Place > >>>Fax: +44 131 475 7001 Edinburgh EH6 5NP > >>>mailto:ronnie@artesyncp.com http://www.artesyncp.com > >>> > >>> > >>> > >>> > >>> > >>-- > >>Randall R. Stewart > >>ITD > >>Cisco Systems Inc. > >>rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) > >> > >> > >> > > > > > > > > > -- > Randall R. Stewart > ITD > Cisco Systems Inc. > rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) > -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon May 5 16:59:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16105 for ; Mon, 5 May 2003 16:59:51 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h45L81703090 for tsvwg-archive@odin.ietf.org; Mon, 5 May 2003 17:08:01 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h45L5b802162; Mon, 5 May 2003 17:05:37 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h45KZM832069 for ; Mon, 5 May 2003 16:35:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14783 for ; Mon, 5 May 2003 16:26:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CmZt-0000aU-00 for tsvwg@ietf.org; Mon, 05 May 2003 16:28:49 -0400 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx with esmtp (Exim 4.12) id 19CmFO-0000Io-00 for tsvwg@ietf.org; Mon, 05 May 2003 16:07:38 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h45K8Hvl001186 for ; Mon, 5 May 2003 13:08:17 -0700 (MST) Received: from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id h45K8A5i017489 for ; Mon, 5 May 2003 15:08:12 -0500 Received: from motorola.com (d50-39f8.cig.mot.com [160.47.57.248]) by il27exb01.cig.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id KK9Z6NRQ; Mon, 5 May 2003 15:08:10 -0500 Message-ID: <3EB6C515.33A00724@motorola.com> Date: Mon, 05 May 2003 15:09:57 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: bidulock@openss7.org CC: Randall Stewart (cisco) , tsvwg@ietf.org, Sellar@az33exr04.mot.com, Ronnie , Sctp-Impl (E-mail) , "Phillip T. Conrad" , Michael =?iso-8859-1?Q?T=FCxen?= , "Michael A. Ramalho" References: <797470E884C6D611B7A500B0D0AA56D04426F1@batistuta.spider.com> <3EB6838D.1040504@cisco.com> <20030505123424.B23984@openss7.org> <3EB6B151.3040506@cisco.com> <20030505133930.C23337@openss7.org> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by motgate.mot.com id h45K8Hvl001186 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h45KZb832145 Subject: [Tsvwg] Re: PR-SCTP question. Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Randy, I agree with you. The solution by Brian sounds good and has far less overhead than adding timer and ack to each FWD-TSN. regards, -Qiaobing "Brian F. G. Bidulock" wrote: > > Randall, > > It would also be interesting to test this solution in Delaware. > > --brian > > On Mon, 05 May 2003, Randall Stewart (cisco) wrote: > > > Brian: > > > > Seems like a much better solution than having a timer.. > > > > so we end up with: > > > > 1) A note in PR-SCTP about the SHUTDOWN cases as you mention. > > > > 2) A note in PR-SCTP regarding SACK's aka a FWD-TSN MUST be > > treated as a DATA chunk in regard to sending SACK's ( I think > > this is needed since there is no mention to it in the document > > currently). > > > > R > > > > > > Brian F. G. Bidulock wrote: > > > > >Randall, > > > > > >If the FWD-TSN is treated in the same fashion as DATA is in the > > >base protocol with regard to the sending of SACK, in this case a > > >SACK would already be required by the base protocol would it > > >not? So I don't think that there is a need for an alteration in > > >SACK processing. IHO the problem appears to be (as you allude) > > >that for a normal DATA transmission there is a retransmit timer > > >running whereas for FWD-TSN there is not. During normal data > > >transmission during the association, this is not problematic > > >because of the rules for sending subsequent FWD-TSN in receipt > > >of SACK. It is only in this case where there is no further data > > >to send. > > > > > >As this only appears to be a problem in this one situation (not > > >subsequent DATA to send and no SACKs forthcoming), it might be > > >possible to handle this with a SHUTDOWN rule such as follows: > > > > > >Whenever the PR-SCTP sender enters the SHUTDOWN-PENDING state, > > >and there are only TSNs marked dropped for retransmission (for > > >which FWD-TSNs have been sent) a SHUTDOWN chunk is sent and the > > >sender enters the SHUTDOWN-SENT state. (The same for > > >SHUTDOWN-RECEIVED and SHUTDOWN-ACK-SENT states.) > > > > > >Whenever the PR-SCTP receiver receives a SHUTDOWN or > > >SHUTDOWN-ACK and there are gaps in its received TSN sequence > > >(messages awaiting reordering before delivery to the user), it > > >will treat the SHUTDOWN or SHUTDOWN-ACK though it were a forward > > >TSN for all missing data chunks. > > > > > >The trick here is to not delay the SHUTDOWN (or SHUTDOWN-ACK) > > >chunk being sent waiting for acknowledgement of dropped TSNs > > >but to send it anyways with the knowledge that the receiver can > > >imply any missing TSNs as having been dropped. > > > > > >I think this would better meet the intent of PR-SCTP (and in > > >particular timed-reliability) as it does not rely on a timer to > > >arrive at the implication of a missed FWD-TSN. The receipt of a > > >SHUTDOWN or SHUTDOWN-ACK can be treated as an implied FWD-TSN > > >for all outstanding data. > > > > > >Under the base protocol, what happens if a sender sends a > > >SHUTDOWN chunk *before* all its sent data is acknowledged? I > > >think an implementation could either complete the shutdown and > > >discard data awaiting reordering, or ABORT the association. For > > >PR-SCTP, receiving SHUTDOWN early could be construed as cause to > > >mark as dropped all outstanding data, and move the cummulative > > >ack point to the "highest" received TSN and complete the > > >SHUTDOWN procedure. > > > > > >Does that make sense? > > > > > >So effectively the rules would be that a SHUTDOWN or > > >SHUTDOWN-ACK should not be delayed in the SHUTDOWN-PENDING or > > >SHUTDOWN-RECEIVED states solely on the basis of unacknowledged > > >but "dropped" TSNs, and that a received SHUTDOWN or SHUTDOWN-ACK > > >chunk that is otherwise valid should be construed by the > > >receiver to have the same effect as a FWD-TSN dropping all > > >outstanding TSNs. > > > > > >Is that simpler than a timer? > > > > > >--brian > > > > > > > > >Whenever the receiver receives > > > > > > > > >On Mon, 05 May 2003, Randall Stewart (cisco) wrote: > > > > > > > > > > > >>Ronnie: > > >> > > >>Nope, I don't think you are missing anything. I have been testing the > > >>internal Cisco-IOS implementation of PR-SCTP against the KAME stack > > >>and have reached the same conclusion. I think we need to require that the > > >>receiver of a FWD-TSN send a SACK in reponse to this. Otherwise > > >>you have this deadlock scenario.... I have made the KAME stack > > >>send the SACK.. but this then begs another question... > > >> > > >>If the SACK in the return path was lost (I am testing at times with > > >>error rates set to 20%... so that happens a lot).. what do we do? > > >> > > >>It almost sounds like we need not only to require a FWD-TSN get > > >>a SACK in response.. but that the sender of the FWD-TSN, if no > > >>other data is being sent, start a timer to retransmit the FWD-TSN > > >>if no SACK is received.. not sure if I worded that clear but I think > > >>it will be needed... > > >> > > >>Co-authors.. what do you-all think? > > >> > > >>R > > >> > > >> > > >>Sellar, Ronnie wrote: > > >> > > >> > > >> > > >>>Hi, > > >>> > > >>>We have just started looking at PR-SCTP with a view to having a prototype > > >>>implementation ready for the next Interop in Delaware and have come up with > > >>>a question regarding the FORWARD-TSN chunk and how it could affect > > >>>association termination. > > >>> > > >>>Consider the following example. Endpoint A has an association with endpoint > > >>>B in which all the data it sends is ordered and marked as 'unreliable' for > > >>>whatever reason. Endpoint A has now sent all the data it wants to send to B > > >>>but can't yet close the association because B has not yet acknowledged one > > >>>of the TSNs. Lets say that it has transmitted TSNs 1-100 but has not yet > > >>>received an acknowledgement of TSN 97 since B has not yet received that TSN. > > >>> > > >>>In this situation A cannot yet send the SHUTDOWN since not all data is acked > > >>>and B has three chunks it cannot deliver to it's user (98, 99 and 100) since > > >>>it has not received 97. When A receives the last SACK it decides that it no > > >>>longer wants to retransmit chunk 97 and so issues a FORWARD-TSN chunk to > > >>>move the cumulative ack TSN on to 100. How does A know that B received the > > >>>FORWARD-TSN chunk ? There is no more data to send so B will not be sending > > >>>any more SACKs. If B sends no more SACKs A's cumulative ack TSN will not > > >>>advance and so he will not be able to send the SHUTDOWN chunk. > > >>> > > >>>In B's case when he receives the FORWARD-TSN he will be happy, deliver > > >>>98-100 to the user and move his cumulative TSN forward. But he is not > > >>>required to send a SACK to tell A he has done so. Are we now in a stalemate > > >>>situation ? > > >>> > > >>>Also consider the case where B never receives the FORWARD-TSN. He is now > > >>>stuck with 98-100 in his buffers which he cannot deliver since he doesn't > > >>>know that 97 is not coming. Have we reached a similar stalemate ? > > >>> > > >>>Perhaps I'm missing something, but I do think there seems to be a problem if > > >>>a FORWARD-TSN chunk is the last chunk to be transmitted on an association. > > >>>Please feel free to correct me if I'm wrong. > > >>> > > >>>Cheers > > >>> > > >>>Ronnie > > >>> > > >>>--- > > >>>Ronnie Sellar Artesyn Communications Products > > >>>Tel: +44 131 475 7015 Suite 4, 2 Anderson Place > > >>>Fax: +44 131 475 7001 Edinburgh EH6 5NP > > >>>mailto:ronnie@artesyncp.com http://www.artesyncp.com > > >>> > > >>> > > >>> > > >>> > > >>> > > >>-- > > >>Randall R. Stewart > > >>ITD > > >>Cisco Systems Inc. > > >>rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) > > >> > > >> > > >> > > > > > > > > > > > > > > > -- > > Randall R. Stewart > > ITD > > Cisco Systems Inc. > > rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) > > > > -- > Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ > bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ > http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ > ¦ Therefore all progress depends on the ¦ > ¦ unreasonable man. -- George Bernard Shaw ¦ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue May 6 05:17:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12360 for ; Tue, 6 May 2003 05:17:43 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h469Q7C03510 for tsvwg-archive@odin.ietf.org; Tue, 6 May 2003 05:26:07 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h469Of803447; Tue, 6 May 2003 05:24:41 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h469Lj803277 for ; Tue, 6 May 2003 05:21:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12268 for ; Tue, 6 May 2003 05:08:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CySp-0004Qf-00 for tsvwg@ietf.org; Tue, 06 May 2003 05:10:19 -0400 Received: from gw.openss7.com ([142.179.199.224] ident=[dBk0Cokfe4yIMRJEZHwGq8+rpPx/eeHW]) by ietf-mx with esmtp (Exim 4.12) id 19CySe-0004Qb-00 for tsvwg@ietf.org; Tue, 06 May 2003 05:10:09 -0400 Received: from ns.pigworks.openss7.net (IDENT:YhJ0YpYZ+bOqB4tVRoZx6zWKOdd9F/z4@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h46946l19451; Tue, 6 May 2003 03:04:06 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h46946h08230; Tue, 6 May 2003 03:04:06 -0600 Date: Tue, 6 May 2003 03:04:05 -0600 From: "Brian F. G. Bidulock" To: =?iso-8859-1?Q?Michael_T=FCxen?= Cc: "Randall Stewart (cisco)" , tsvwg@ietf.org, "Sellar, Ronnie" , "Sctp-Impl (E-mail)" , "Phillip T. Conrad" , Qiaobing Xie , "Michael A. Ramalho" Message-ID: <20030506030405.A7706@openss7.org> Reply-To: bidulock@openss7.org References: <20030505123424.B23984@openss7.org> <04285F65-7F98-11D7-B5AF-0030654C1AB6@fh-muenster.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <04285F65-7F98-11D7-B5AF-0030654C1AB6@fh-muenster.de>; from tuexen@fh-muenster.de on Tue, May 06, 2003 at 09:54:51AM +0200 Organization: http://www.openss7.org/ Dsn-Notification-To: X-MIME-Autoconverted: from 8bit to quoted-printable by gw.openss7.com id h46946l19451 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h469NZ803399 Subject: [Tsvwg] Re: PR-SCTP question. Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Michael, Yes, I was thinking there might be a problem during transmission too. However, as t3-rtx is never running in this circumstance, yet the sender of the FWD-TSN can indeed expect a SACK within an RTO for the FWD-TSN. So, it would be possible to borrow the t3-rtx timer (rather than adding a new one) to solve this siutation as follows: When the sender sends a FWD-TSN and there is no unacknowledged data remaining, resulting from the dropped TSNs, that t3-rtx SHOULD NOT be stopped. This would be an alteration to rule A2). In addition, when the t3-trx timer expires, normal base protocol retransmission would occur and, in addition, if the cummulative TSN ack point is less than the Advanced.Peer.Ack.Point that in addition to normal retransmission a FWD-TSN be bundled with any retransmitted DATA chunks indicating the Advanced.Peer.Ack.Point (again) to the receiver. This would be an additional rule, say A4. That is, one could make retransmission of the FWD-TSN subject to the same rules as would have applied to the DATA had it not been dropped. Coupled this with making the FWD-TSN at the receiver subject to the same rules visa vi SACK as the received DATA would have been subject. (This would also be an addition as Randall notes.) Then all cases of retransmission of FWD-TSN would be handled in the same fashion as the base protocol and none of these problems can any longer ensue. Modifications to SHUTDOWN would then no longer be required. Also, no additional timers would be required. One can then think of the FWD-TSN as a compressed placeholder for the DATA that was dropped. If the place holder is subject to the same retramission (t3-rtx) and acknowledgement (SACK) rules as the DATA it represents, then the only variation from the base protocol is that the data itself does not need to be retransmitted once expired, and the place holders for a number of DATA chunks can be represented in a single FWD-TSN. I think the change would be minor in implementation (not stop T3-rtx when only dropped data is outstanding and consider retransmission of FWD-TSN when considering DATA for retransmission). Note that the SHUTDOWN case is also handled (because now the FWD-TSN for the dropped TSN 97 would be retransmitted on T3-rtx, and T3-rtx would be restarted, retransmission pegs counted, ... just as though the data for TSN 97 were being retransmitted.) How does that sound? Is that a better and more complete solution proposal? --brian On Tue, 06 May 2003, Michael Tüxen wrote: > Hi all, > > Brians solution handles the case at the end of live of an association. > > Consider this case: > > A sends TSN 0,1,2 on stream 0, all ordered. TSN 0 gets dropped in the > network. > TSN 1 and TSN 2 arrive and get SACKed. Now the sender drops (in the > sense of > PR-SCTP) TSN 0 and sends a FWD-TSN chunk which is dropped in the > network. > The sender now has no timers running, the receiver waits for TSN 0 to > deliver > TSN 1 and TSN 2 to the upper layer. > > This situation is not changed until the Upper Layer on the sender side > decides > to send more data or initiates the shutdown procedure. > > Did I miss something? > > Best regards > Michael > > On Monday, May 5, 2003, at 20:34 Europe/Berlin, Brian F. G. Bidulock > wrote: > > > Randall, > > > > If the FWD-TSN is treated in the same fashion as DATA is in the > > base protocol with regard to the sending of SACK, in this case a > > SACK would already be required by the base protocol would it > > not? So I don't think that there is a need for an alteration in > > SACK processing. IHO the problem appears to be (as you allude) > > that for a normal DATA transmission there is a retransmit timer > > running whereas for FWD-TSN there is not. During normal data > > transmission during the association, this is not problematic > > because of the rules for sending subsequent FWD-TSN in receipt > > of SACK. It is only in this case where there is no further data > > to send. > > > > As this only appears to be a problem in this one situation (not > > subsequent DATA to send and no SACKs forthcoming), it might be > > possible to handle this with a SHUTDOWN rule such as follows: > > > > Whenever the PR-SCTP sender enters the SHUTDOWN-PENDING state, > > and there are only TSNs marked dropped for retransmission (for > > which FWD-TSNs have been sent) a SHUTDOWN chunk is sent and the > > sender enters the SHUTDOWN-SENT state. (The same for > > SHUTDOWN-RECEIVED and SHUTDOWN-ACK-SENT states.) > > > > Whenever the PR-SCTP receiver receives a SHUTDOWN or > > SHUTDOWN-ACK and there are gaps in its received TSN sequence > > (messages awaiting reordering before delivery to the user), it > > will treat the SHUTDOWN or SHUTDOWN-ACK though it were a forward > > TSN for all missing data chunks. > > > > The trick here is to not delay the SHUTDOWN (or SHUTDOWN-ACK) > > chunk being sent waiting for acknowledgement of dropped TSNs > > but to send it anyways with the knowledge that the receiver can > > imply any missing TSNs as having been dropped. > > > > I think this would better meet the intent of PR-SCTP (and in > > particular timed-reliability) as it does not rely on a timer to > > arrive at the implication of a missed FWD-TSN. The receipt of a > > SHUTDOWN or SHUTDOWN-ACK can be treated as an implied FWD-TSN > > for all outstanding data. > > > > Under the base protocol, what happens if a sender sends a > > SHUTDOWN chunk *before* all its sent data is acknowledged? I > > think an implementation could either complete the shutdown and > > discard data awaiting reordering, or ABORT the association. For > > PR-SCTP, receiving SHUTDOWN early could be construed as cause to > > mark as dropped all outstanding data, and move the cummulative > > ack point to the "highest" received TSN and complete the > > SHUTDOWN procedure. > > > > Does that make sense? > > > > So effectively the rules would be that a SHUTDOWN or > > SHUTDOWN-ACK should not be delayed in the SHUTDOWN-PENDING or > > SHUTDOWN-RECEIVED states solely on the basis of unacknowledged > > but "dropped" TSNs, and that a received SHUTDOWN or SHUTDOWN-ACK > > chunk that is otherwise valid should be construed by the > > receiver to have the same effect as a FWD-TSN dropping all > > outstanding TSNs. > > > > Is that simpler than a timer? > > > > --brian > > > > > > Whenever the receiver receives > > > > > > On Mon, 05 May 2003, Randall Stewart (cisco) wrote: > > > >> Ronnie: > >> > >> Nope, I don't think you are missing anything. I have been testing the > >> internal Cisco-IOS implementation of PR-SCTP against the KAME stack > >> and have reached the same conclusion. I think we need to require that > >> the > >> receiver of a FWD-TSN send a SACK in reponse to this. Otherwise > >> you have this deadlock scenario.... I have made the KAME stack > >> send the SACK.. but this then begs another question... > >> > >> If the SACK in the return path was lost (I am testing at times with > >> error rates set to 20%... so that happens a lot).. what do we do? > >> > >> It almost sounds like we need not only to require a FWD-TSN get > >> a SACK in response.. but that the sender of the FWD-TSN, if no > >> other data is being sent, start a timer to retransmit the FWD-TSN > >> if no SACK is received.. not sure if I worded that clear but I think > >> it will be needed... > >> > >> Co-authors.. what do you-all think? > >> > >> R > >> > >> > >> Sellar, Ronnie wrote: > >> > >>> Hi, > >>> > >>> We have just started looking at PR-SCTP with a view to having a > >>> prototype > >>> implementation ready for the next Interop in Delaware and have come > >>> up with > >>> a question regarding the FORWARD-TSN chunk and how it could affect > >>> association termination. > >>> > >>> Consider the following example. Endpoint A has an association with > >>> endpoint > >>> B in which all the data it sends is ordered and marked as > >>> 'unreliable' for > >>> whatever reason. Endpoint A has now sent all the data it wants to > >>> send to B > >>> but can't yet close the association because B has not yet > >>> acknowledged one > >>> of the TSNs. Lets say that it has transmitted TSNs 1-100 but has > >>> not yet > >>> received an acknowledgement of TSN 97 since B has not yet received > >>> that TSN. > >>> > >>> In this situation A cannot yet send the SHUTDOWN since not all data > >>> is acked > >>> and B has three chunks it cannot deliver to it's user (98, 99 and > >>> 100) since > >>> it has not received 97. When A receives the last SACK it decides > >>> that it no > >>> longer wants to retransmit chunk 97 and so issues a FORWARD-TSN > >>> chunk to > >>> move the cumulative ack TSN on to 100. How does A know that B > >>> received the > >>> FORWARD-TSN chunk ? There is no more data to send so B will not be > >>> sending > >>> any more SACKs. If B sends no more SACKs A's cumulative ack TSN > >>> will not > >>> advance and so he will not be able to send the SHUTDOWN chunk. > >>> > >>> In B's case when he receives the FORWARD-TSN he will be happy, > >>> deliver > >>> 98-100 to the user and move his cumulative TSN forward. But he is > >>> not > >>> required to send a SACK to tell A he has done so. Are we now in a > >>> stalemate > >>> situation ? > >>> > >>> Also consider the case where B never receives the FORWARD-TSN. He > >>> is now > >>> stuck with 98-100 in his buffers which he cannot deliver since he > >>> doesn't > >>> know that 97 is not coming. Have we reached a similar stalemate ? > >>> > >>> Perhaps I'm missing something, but I do think there seems to be a > >>> problem if > >>> a FORWARD-TSN chunk is the last chunk to be transmitted on an > >>> association. > >>> Please feel free to correct me if I'm wrong. > >>> > >>> Cheers > >>> > >>> Ronnie > >>> > >>> --- > >>> Ronnie Sellar Artesyn Communications Products > >>> Tel: +44 131 475 7015 Suite 4, 2 Anderson Place > >>> Fax: +44 131 475 7001 Edinburgh EH6 5NP > >>> mailto:ronnie@artesyncp.com http://www.artesyncp.com > >>> > >>> > >>> > >> > >> > >> -- > >> Randall R. Stewart > >> ITD > >> Cisco Systems Inc. > >> rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) > >> > > > > -- > > Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ > > bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ > > http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ > > ¦ Therefore all progress depends on the ¦ > > ¦ unreasonable man. -- George Bernard Shaw ¦ > > -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue May 6 08:23:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17303 for ; Tue, 6 May 2003 08:23:13 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h46CVg217766 for tsvwg-archive@odin.ietf.org; Tue, 6 May 2003 08:31:42 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46CUB817676; Tue, 6 May 2003 08:30:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46CTQ817618 for ; Tue, 6 May 2003 08:29:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16995; Tue, 6 May 2003 08:17:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D1Q1-0005Xk-00; Tue, 06 May 2003 08:19:37 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by ietf-mx with esmtp (Exim 4.12) id 19D1Pv-0005XV-00; Tue, 06 May 2003 08:19:31 -0400 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h46BofXp001165; Tue, 6 May 2003 04:50:45 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AGW18144; Tue, 6 May 2003 04:50:39 -0700 (PDT) Message-ID: <3EB7A18C.1060304@cisco.com> Date: Tue, 06 May 2003 06:50:36 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3) Gecko/20030502 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org CC: tsvwg@ietf.org, "Sellar, Ronnie" , "Sctp-Impl (E-mail)" , "Phillip T. Conrad" , Qiaobing Xie , =?ISO-8859-1?Q?Michael_T=FCxen?= , "Michael A. Ramalho" References: <797470E884C6D611B7A500B0D0AA56D04426F1@batistuta.spider.com> <3EB6838D.1040504@cisco.com> <20030505123424.B23984@openss7.org> <3EB6B151.3040506@cisco.com> <20030505133930.C23337@openss7.org> In-Reply-To: <20030505133930.C23337@openss7.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Tsvwg] Re: PR-SCTP question. Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Great idea.. we will have to see if we can squeeze in the test.. I think this time we have a lot more time to test so we should get a bit futher :> R Brian F. G. Bidulock wrote: >Randall, > >It would also be interesting to test this solution in Delaware. > >--brian > >On Mon, 05 May 2003, Randall Stewart (cisco) wrote: > > > >>Brian: >> >>Seems like a much better solution than having a timer.. >> >>so we end up with: >> >>1) A note in PR-SCTP about the SHUTDOWN cases as you mention. >> >>2) A note in PR-SCTP regarding SACK's aka a FWD-TSN MUST be >> treated as a DATA chunk in regard to sending SACK's ( I think >> this is needed since there is no mention to it in the document >> currently). >> >>R >> >> >>Brian F. G. Bidulock wrote: >> >> >> >>>Randall, >>> >>>If the FWD-TSN is treated in the same fashion as DATA is in the >>>base protocol with regard to the sending of SACK, in this case a >>>SACK would already be required by the base protocol would it >>>not? So I don't think that there is a need for an alteration in >>>SACK processing. IHO the problem appears to be (as you allude) >>>that for a normal DATA transmission there is a retransmit timer >>>running whereas for FWD-TSN there is not. During normal data >>>transmission during the association, this is not problematic >>>because of the rules for sending subsequent FWD-TSN in receipt >>>of SACK. It is only in this case where there is no further data >>>to send. >>> >>>As this only appears to be a problem in this one situation (not >>>subsequent DATA to send and no SACKs forthcoming), it might be >>>possible to handle this with a SHUTDOWN rule such as follows: >>> >>>Whenever the PR-SCTP sender enters the SHUTDOWN-PENDING state, >>>and there are only TSNs marked dropped for retransmission (for >>>which FWD-TSNs have been sent) a SHUTDOWN chunk is sent and the >>>sender enters the SHUTDOWN-SENT state. (The same for >>>SHUTDOWN-RECEIVED and SHUTDOWN-ACK-SENT states.) >>> >>>Whenever the PR-SCTP receiver receives a SHUTDOWN or >>>SHUTDOWN-ACK and there are gaps in its received TSN sequence >>>(messages awaiting reordering before delivery to the user), it >>>will treat the SHUTDOWN or SHUTDOWN-ACK though it were a forward >>>TSN for all missing data chunks. >>> >>>The trick here is to not delay the SHUTDOWN (or SHUTDOWN-ACK) >>>chunk being sent waiting for acknowledgement of dropped TSNs >>>but to send it anyways with the knowledge that the receiver can >>>imply any missing TSNs as having been dropped. >>> >>>I think this would better meet the intent of PR-SCTP (and in >>>particular timed-reliability) as it does not rely on a timer to >>>arrive at the implication of a missed FWD-TSN. The receipt of a >>>SHUTDOWN or SHUTDOWN-ACK can be treated as an implied FWD-TSN >>>for all outstanding data. >>> >>>Under the base protocol, what happens if a sender sends a >>>SHUTDOWN chunk *before* all its sent data is acknowledged? I >>>think an implementation could either complete the shutdown and >>>discard data awaiting reordering, or ABORT the association. For >>>PR-SCTP, receiving SHUTDOWN early could be construed as cause to >>>mark as dropped all outstanding data, and move the cummulative >>>ack point to the "highest" received TSN and complete the >>>SHUTDOWN procedure. >>> >>>Does that make sense? >>> >>>So effectively the rules would be that a SHUTDOWN or >>>SHUTDOWN-ACK should not be delayed in the SHUTDOWN-PENDING or >>>SHUTDOWN-RECEIVED states solely on the basis of unacknowledged >>>but "dropped" TSNs, and that a received SHUTDOWN or SHUTDOWN-ACK >>>chunk that is otherwise valid should be construed by the >>>receiver to have the same effect as a FWD-TSN dropping all >>>outstanding TSNs. >>> >>>Is that simpler than a timer? >>> >>>--brian >>> >>> >>>Whenever the receiver receives >>> >>> >>>On Mon, 05 May 2003, Randall Stewart (cisco) wrote: >>> >>> >>> >>> >>> >>>>Ronnie: >>>> >>>>Nope, I don't think you are missing anything. I have been testing the >>>>internal Cisco-IOS implementation of PR-SCTP against the KAME stack >>>>and have reached the same conclusion. I think we need to require that the >>>>receiver of a FWD-TSN send a SACK in reponse to this. Otherwise >>>>you have this deadlock scenario.... I have made the KAME stack >>>>send the SACK.. but this then begs another question... >>>> >>>>If the SACK in the return path was lost (I am testing at times with >>>>error rates set to 20%... so that happens a lot).. what do we do? >>>> >>>>It almost sounds like we need not only to require a FWD-TSN get >>>>a SACK in response.. but that the sender of the FWD-TSN, if no >>>>other data is being sent, start a timer to retransmit the FWD-TSN >>>>if no SACK is received.. not sure if I worded that clear but I think >>>>it will be needed... >>>> >>>>Co-authors.. what do you-all think? >>>> >>>>R >>>> >>>> >>>>Sellar, Ronnie wrote: >>>> >>>> >>>> >>>> >>>> >>>>>Hi, >>>>> >>>>>We have just started looking at PR-SCTP with a view to having a prototype >>>>>implementation ready for the next Interop in Delaware and have come up with >>>>>a question regarding the FORWARD-TSN chunk and how it could affect >>>>>association termination. >>>>> >>>>>Consider the following example. Endpoint A has an association with endpoint >>>>>B in which all the data it sends is ordered and marked as 'unreliable' for >>>>>whatever reason. Endpoint A has now sent all the data it wants to send to B >>>>>but can't yet close the association because B has not yet acknowledged one >>>>>of the TSNs. Lets say that it has transmitted TSNs 1-100 but has not yet >>>>>received an acknowledgement of TSN 97 since B has not yet received that TSN. >>>>> >>>>>In this situation A cannot yet send the SHUTDOWN since not all data is acked >>>>>and B has three chunks it cannot deliver to it's user (98, 99 and 100) since >>>>>it has not received 97. When A receives the last SACK it decides that it no >>>>>longer wants to retransmit chunk 97 and so issues a FORWARD-TSN chunk to >>>>>move the cumulative ack TSN on to 100. How does A know that B received the >>>>>FORWARD-TSN chunk ? There is no more data to send so B will not be sending >>>>>any more SACKs. If B sends no more SACKs A's cumulative ack TSN will not >>>>>advance and so he will not be able to send the SHUTDOWN chunk. >>>>> >>>>>In B's case when he receives the FORWARD-TSN he will be happy, deliver >>>>>98-100 to the user and move his cumulative TSN forward. But he is not >>>>>required to send a SACK to tell A he has done so. Are we now in a stalemate >>>>>situation ? >>>>> >>>>>Also consider the case where B never receives the FORWARD-TSN. He is now >>>>>stuck with 98-100 in his buffers which he cannot deliver since he doesn't >>>>>know that 97 is not coming. Have we reached a similar stalemate ? >>>>> >>>>>Perhaps I'm missing something, but I do think there seems to be a problem if >>>>>a FORWARD-TSN chunk is the last chunk to be transmitted on an association. >>>>>Please feel free to correct me if I'm wrong. >>>>> >>>>>Cheers >>>>> >>>>>Ronnie >>>>> >>>>>--- >>>>>Ronnie Sellar Artesyn Communications Products >>>>>Tel: +44 131 475 7015 Suite 4, 2 Anderson Place >>>>>Fax: +44 131 475 7001 Edinburgh EH6 5NP >>>>>mailto:ronnie@artesyncp.com http://www.artesyncp.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>-- >>>>Randall R. Stewart >>>>ITD >>>>Cisco Systems Inc. >>>>rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>-- >>Randall R. Stewart >>ITD >>Cisco Systems Inc. >>rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) >> >> >> > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue May 6 08:35:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18384 for ; Tue, 6 May 2003 08:35:57 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h46CiQK19278 for tsvwg-archive@odin.ietf.org; Tue, 6 May 2003 08:44:26 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46CfF819168; Tue, 6 May 2003 08:41:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46CeJ819126 for ; Tue, 6 May 2003 08:40:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18135; Tue, 6 May 2003 08:31:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D1dN-0005q7-00; Tue, 06 May 2003 08:33:25 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by ietf-mx with esmtp (Exim 4.12) id 19D1dF-0005pH-00; Tue, 06 May 2003 08:33:18 -0400 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h46BvGXp004976; Tue, 6 May 2003 04:57:19 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AGW18381; Tue, 6 May 2003 04:57:14 -0700 (PDT) Message-ID: <3EB7A31A.3020500@cisco.com> Date: Tue, 06 May 2003 06:57:14 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3) Gecko/20030502 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Sellar, Ronnie" CC: "'bidulock@openss7.org'" , =?ISO-8859-1?Q?Micha?= =?ISO-8859-1?Q?el_T=FCxen?= , tsvwg@ietf.org, "Sctp-Impl (E-mail)" , "Phillip T. Conrad" , Qiaobing Xie , "Michael A. Ramalho" References: <797470E884C6D611B7A500B0D0AA56D04426F4@batistuta.spider.com> In-Reply-To: <797470E884C6D611B7A500B0D0AA56D04426F4@batistuta.spider.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by sj-core-1.cisco.com id h46BvGXp004976 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h46CeJ819127 Subject: [Tsvwg] Re: PR-SCTP question. Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Ronnie/Brian: I think this is the correct solution... It then requires: 1) A note on the receiver side .. aka handle like data .. you must start the sack timer etc and 2) A note on the sender side.. aka you don't stop the t3-timer if there is no outstanding data.. and when the t3-timer goes off you should send a fwd-tsn as well as any retransmmitted data.. I will see if I can't cut and past from this email and do a bit of massaging to get the proper notes in the document.. I too view the FWD-TSN as nothing but a compressed "heres the data I am skipping and not sending"... R Sellar, Ronnie wrote: >Brian, > >This does sound a better solution to me. It means that >SHUTDOWN/SHUTDOWN-ACK processing is not affected and it also fixes Michael's >problem of stuck data in the middle of an association. > >Regards > >Ronnie >--- >Ronnie Sellar Artesyn Communications Products >Tel: +44 131 475 7015 Suite 4, 2 Anderson Place >Fax: +44 131 475 7001 Edinburgh EH6 5NP >mailto:ronnie@artesyncp.com http://www.artesyncp.com > > > >>-----Original Message----- >>From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] >>Sent: 06 May 2003 10:04 >>To: Michael Tüxen >>Cc: Randall Stewart (cisco); tsvwg@ietf.org; Sellar, Ronnie; Sctp-Impl >>(E-mail); Phillip T. Conrad; Qiaobing Xie; Michael A. Ramalho >>Subject: Re: PR-SCTP question. >> >> >>Michael, >> >>Yes, I was thinking there might be a problem during transmission too. >> >>However, as t3-rtx is never running in this circumstance, yet >>the sender >>of the FWD-TSN can indeed expect a SACK within an RTO for the FWD-TSN. >> >>So, it would be possible to borrow the t3-rtx timer (rather >>than adding >>a new one) to solve this siutation as follows: >> >>When the sender sends a FWD-TSN and there is no unacknowledged data >>remaining, resulting from the dropped TSNs, that t3-rtx SHOULD NOT be >>stopped. This would be an alteration to rule A2). >> >>In addition, when the t3-trx timer expires, normal base protocol >>retransmission would occur and, in addition, if the >>cummulative TSN ack >>point is less than the Advanced.Peer.Ack.Point that in addition to >>normal retransmission a FWD-TSN be bundled with any retransmitted DATA >>chunks indicating the Advanced.Peer.Ack.Point (again) to the receiver. >>This would be an additional rule, say A4. >> >>That is, one could make retransmission of the FWD-TSN subject to the >>same rules as would have applied to the DATA had it not been dropped. >> >>Coupled this with making the FWD-TSN at the receiver subject >>to the same >>rules visa vi SACK as the received DATA would have been >>subject. (This >>would also be an addition as Randall notes.) >> >>Then all cases of retransmission of FWD-TSN would be handled >>in the same >>fashion as the base protocol and none of these problems can any longer >>ensue. Modifications to SHUTDOWN would then no longer be required. >>Also, no additional timers would be required. >> >>One can then think of the FWD-TSN as a compressed placeholder for the >>DATA that was dropped. If the place holder is subject to the same >>retramission (t3-rtx) and acknowledgement (SACK) rules as the DATA it >>represents, then the only variation from the base protocol is that the >>data itself does not need to be retransmitted once expired, and the >>place holders for a number of DATA chunks can be represented >>in a single >>FWD-TSN. >> >>I think the change would be minor in implementation (not stop T3-rtx >>when only dropped data is outstanding and consider retransmission of >>FWD-TSN when considering DATA for retransmission). >> >>Note that the SHUTDOWN case is also handled (because now the >>FWD-TSN for >>the dropped TSN 97 would be retransmitted on T3-rtx, and >>T3-rtx would be >>restarted, retransmission pegs counted, ... just as though >>the data for >>TSN 97 were being retransmitted.) >> >>How does that sound? >> >>Is that a better and more complete solution proposal? >> >>--brian >> >>On Tue, 06 May 2003, Michael Tüxen wrote: >> >> >> >>>Hi all, >>> >>>Brians solution handles the case at the end of live of an >>> >>> >>association. >> >> >>>Consider this case: >>> >>>A sends TSN 0,1,2 on stream 0, all ordered. TSN 0 gets >>> >>> >>dropped in the >> >> >>>network. >>>TSN 1 and TSN 2 arrive and get SACKed. Now the sender drops (in the >>>sense of >>>PR-SCTP) TSN 0 and sends a FWD-TSN chunk which is dropped in the >>>network. >>>The sender now has no timers running, the receiver waits >>> >>> >>for TSN 0 to >> >> >>>deliver >>>TSN 1 and TSN 2 to the upper layer. >>> >>>This situation is not changed until the Upper Layer on the >>> >>> >>sender side >> >> >>>decides >>>to send more data or initiates the shutdown procedure. >>> >>>Did I miss something? >>> >>>Best regards >>>Michael >>> >>>On Monday, May 5, 2003, at 20:34 Europe/Berlin, Brian F. G. >>> >>> >>Bidulock >> >> >>>wrote: >>> >>> >>> >>>>Randall, >>>> >>>>If the FWD-TSN is treated in the same fashion as DATA is in the >>>>base protocol with regard to the sending of SACK, in this case a >>>>SACK would already be required by the base protocol would it >>>>not? So I don't think that there is a need for an alteration in >>>>SACK processing. IHO the problem appears to be (as you allude) >>>>that for a normal DATA transmission there is a retransmit timer >>>>running whereas for FWD-TSN there is not. During normal data >>>>transmission during the association, this is not problematic >>>>because of the rules for sending subsequent FWD-TSN in receipt >>>>of SACK. It is only in this case where there is no further data >>>>to send. >>>> >>>>As this only appears to be a problem in this one situation (not >>>>subsequent DATA to send and no SACKs forthcoming), it might be >>>>possible to handle this with a SHUTDOWN rule such as follows: >>>> >>>>Whenever the PR-SCTP sender enters the SHUTDOWN-PENDING state, >>>>and there are only TSNs marked dropped for retransmission (for >>>>which FWD-TSNs have been sent) a SHUTDOWN chunk is sent and the >>>>sender enters the SHUTDOWN-SENT state. (The same for >>>>SHUTDOWN-RECEIVED and SHUTDOWN-ACK-SENT states.) >>>> >>>>Whenever the PR-SCTP receiver receives a SHUTDOWN or >>>>SHUTDOWN-ACK and there are gaps in its received TSN sequence >>>>(messages awaiting reordering before delivery to the user), it >>>>will treat the SHUTDOWN or SHUTDOWN-ACK though it were a forward >>>>TSN for all missing data chunks. >>>> >>>>The trick here is to not delay the SHUTDOWN (or SHUTDOWN-ACK) >>>>chunk being sent waiting for acknowledgement of dropped TSNs >>>>but to send it anyways with the knowledge that the receiver can >>>>imply any missing TSNs as having been dropped. >>>> >>>>I think this would better meet the intent of PR-SCTP (and in >>>>particular timed-reliability) as it does not rely on a timer to >>>>arrive at the implication of a missed FWD-TSN. The receipt of a >>>>SHUTDOWN or SHUTDOWN-ACK can be treated as an implied FWD-TSN >>>>for all outstanding data. >>>> >>>>Under the base protocol, what happens if a sender sends a >>>>SHUTDOWN chunk *before* all its sent data is acknowledged? I >>>>think an implementation could either complete the shutdown and >>>>discard data awaiting reordering, or ABORT the association. For >>>>PR-SCTP, receiving SHUTDOWN early could be construed as cause to >>>>mark as dropped all outstanding data, and move the cummulative >>>>ack point to the "highest" received TSN and complete the >>>>SHUTDOWN procedure. >>>> >>>>Does that make sense? >>>> >>>>So effectively the rules would be that a SHUTDOWN or >>>>SHUTDOWN-ACK should not be delayed in the SHUTDOWN-PENDING or >>>>SHUTDOWN-RECEIVED states solely on the basis of unacknowledged >>>>but "dropped" TSNs, and that a received SHUTDOWN or SHUTDOWN-ACK >>>>chunk that is otherwise valid should be construed by the >>>>receiver to have the same effect as a FWD-TSN dropping all >>>>outstanding TSNs. >>>> >>>>Is that simpler than a timer? >>>> >>>>--brian >>>> >>>> >>>>Whenever the receiver receives >>>> >>>> >>>>On Mon, 05 May 2003, Randall Stewart (cisco) wrote: >>>> >>>> >>>> >>>>>Ronnie: >>>>> >>>>>Nope, I don't think you are missing anything. I have >>>>> >>>>> >>been testing the >> >> >>>>>internal Cisco-IOS implementation of PR-SCTP against the >>>>> >>>>> >>KAME stack >> >> >>>>>and have reached the same conclusion. I think we need to >>>>> >>>>> >>require that >> >> >>>>>the >>>>>receiver of a FWD-TSN send a SACK in reponse to this. Otherwise >>>>>you have this deadlock scenario.... I have made the KAME stack >>>>>send the SACK.. but this then begs another question... >>>>> >>>>>If the SACK in the return path was lost (I am testing at >>>>> >>>>> >>times with >> >> >>>>>error rates set to 20%... so that happens a lot).. what do we do? >>>>> >>>>>It almost sounds like we need not only to require a FWD-TSN get >>>>>a SACK in response.. but that the sender of the FWD-TSN, if no >>>>>other data is being sent, start a timer to retransmit the FWD-TSN >>>>>if no SACK is received.. not sure if I worded that clear >>>>> >>>>> >>but I think >> >> >>>>>it will be needed... >>>>> >>>>>Co-authors.. what do you-all think? >>>>> >>>>>R >>>>> >>>>> >>>>>Sellar, Ronnie wrote: >>>>> >>>>> >>>>> >>>>>>Hi, >>>>>> >>>>>>We have just started looking at PR-SCTP with a view to having a >>>>>>prototype >>>>>>implementation ready for the next Interop in Delaware >>>>>> >>>>>> >>and have come >> >> >>>>>>up with >>>>>>a question regarding the FORWARD-TSN chunk and how it >>>>>> >>>>>> >>could affect >> >> >>>>>>association termination. >>>>>> >>>>>>Consider the following example. Endpoint A has an >>>>>> >>>>>> >>association with >> >> >>>>>>endpoint >>>>>>B in which all the data it sends is ordered and marked as >>>>>>'unreliable' for >>>>>>whatever reason. Endpoint A has now sent all the data >>>>>> >>>>>> >>it wants to >> >> >>>>>>send to B >>>>>>but can't yet close the association because B has not yet >>>>>>acknowledged one >>>>>>of the TSNs. Lets say that it has transmitted TSNs >>>>>> >>>>>> >>1-100 but has >> >> >>>>>>not yet >>>>>>received an acknowledgement of TSN 97 since B has not >>>>>> >>>>>> >>yet received >> >> >>>>>>that TSN. >>>>>> >>>>>>In this situation A cannot yet send the SHUTDOWN since >>>>>> >>>>>> >>not all data >> >> >>>>>>is acked >>>>>>and B has three chunks it cannot deliver to it's user >>>>>> >>>>>> >>(98, 99 and >> >> >>>>>>100) since >>>>>>it has not received 97. When A receives the last SACK >>>>>> >>>>>> >>it decides >> >> >>>>>>that it no >>>>>>longer wants to retransmit chunk 97 and so issues a FORWARD-TSN >>>>>>chunk to >>>>>>move the cumulative ack TSN on to 100. How does A know that B >>>>>>received the >>>>>>FORWARD-TSN chunk ? There is no more data to send so B >>>>>> >>>>>> >>will not be >> >> >>>>>>sending >>>>>>any more SACKs. If B sends no more SACKs A's >>>>>> >>>>>> >>cumulative ack TSN >> >> >>>>>>will not >>>>>>advance and so he will not be able to send the SHUTDOWN chunk. >>>>>> >>>>>>In B's case when he receives the FORWARD-TSN he will be happy, >>>>>>deliver >>>>>>98-100 to the user and move his cumulative TSN forward. >>>>>> >>>>>> >> But he is >> >> >>>>>>not >>>>>>required to send a SACK to tell A he has done so. Are >>>>>> >>>>>> >>we now in a >> >> >>>>>>stalemate >>>>>>situation ? >>>>>> >>>>>>Also consider the case where B never receives the >>>>>> >>>>>> >>FORWARD-TSN. He >> >> >>>>>>is now >>>>>>stuck with 98-100 in his buffers which he cannot >>>>>> >>>>>> >>deliver since he >> >> >>>>>>doesn't >>>>>>know that 97 is not coming. Have we reached a similar >>>>>> >>>>>> >>stalemate ? >> >> >>>>>>Perhaps I'm missing something, but I do think there >>>>>> >>>>>> >>seems to be a >> >> >>>>>>problem if >>>>>>a FORWARD-TSN chunk is the last chunk to be transmitted on an >>>>>>association. >>>>>>Please feel free to correct me if I'm wrong. >>>>>> >>>>>>Cheers >>>>>> >>>>>>Ronnie >>>>>> >>>>>>--- >>>>>>Ronnie Sellar Artesyn Communications Products >>>>>>Tel: +44 131 475 7015 Suite 4, 2 Anderson Place >>>>>>Fax: +44 131 475 7001 Edinburgh EH6 5NP >>>>>>mailto:ronnie@artesyncp.com http://www.artesyncp.com >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>-- >>>>>Randall R. Stewart >>>>>ITD >>>>>Cisco Systems Inc. >>>>>rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) >>>>> >>>>> >>>>> >>>>-- >>>>Brian F. G. Bidulock ¦ The reasonable man adapts >>>> >>>> >>himself to the ¦ >> >> >>>>bidulock@openss7.org ¦ world; the unreasonable one >>>> >>>> >>persists in ¦ >> >> >>>>http://www.openss7.org/ ¦ trying to adapt the world to >>>> >>>> >>himself. ¦ >> >> >>>> ¦ Therefore all progress >>>> >>>> >>depends on the ¦ >> >> >>>> ¦ unreasonable man. -- George >>>> >>>> >>Bernard Shaw ¦ >> >> >>-- >>Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ >>bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ >>http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ >> ¦ Therefore all progress depends on the ¦ >> ¦ unreasonable man. -- George Bernard Shaw ¦ >> >> > > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue May 6 13:15:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29957 for ; Tue, 6 May 2003 13:15:41 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h46HOGA10198 for tsvwg-archive@odin.ietf.org; Tue, 6 May 2003 13:24:16 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46HMo810125; Tue, 6 May 2003 13:22:50 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46HLM810034 for ; Tue, 6 May 2003 13:21:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29864 for ; Tue, 6 May 2003 13:12:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D61H-0000gD-00 for tsvwg@ietf.org; Tue, 06 May 2003 13:14:23 -0400 Received: from motgate2.mot.com ([136.182.1.10]) by ietf-mx with esmtp (Exim 4.12) id 19D61G-0000fy-00 for tsvwg@ietf.org; Tue, 06 May 2003 13:14:22 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h46HF7I2007997 for ; Tue, 6 May 2003 10:15:07 -0700 (MST) Received: from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h46HEtac003612 for ; Tue, 6 May 2003 12:14:55 -0500 Received: from motorola.com (d50-39f8.cig.mot.com [160.47.57.248]) by il27exb01.cig.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id KK9Z7JR0; Tue, 6 May 2003 12:14:55 -0500 Message-ID: <3EB7EDFD.97CAA0CC@motorola.com> Date: Tue, 06 May 2003 12:16:45 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Randall Stewart (cisco)" CC: Sellar@il06exr01.mot.com, Ronnie , "'bidulock@openss7.org'" , Michael =?iso-8859-1?Q?T=FCxen?= , tsvwg@ietf.org, Sctp-Impl (E-mail) , "Phillip T. Conrad" , "Michael A. Ramalho" References: <797470E884C6D611B7A500B0D0AA56D04426F4@batistuta.spider.com> <3EB7A31A.3020500@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Tsvwg] Re: PR-SCTP question. Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit "Randall Stewart (cisco)" wrote: > > Ronnie/Brian: > > I think this is the correct solution... > > It then requires: > > 1) A note on the receiver side .. aka handle like data .. you must start the > sack timer etc > > and > > 2) A note on the sender side.. aka you don't stop the t3-timer if there > is no outstanding data.. and when the t3-timer goes off you should > send a fwd-tsn as well as any retransmmitted data.. > > I will see if I can't cut and past from this email and do a bit > of massaging to get the proper notes in the document.. > > I too view the FWD-TSN as nothing but a compressed "heres the data > I am skipping and not sending"... This is indeed a good way to look at it. And I think the solution summarized by Brian and Randy is the right approach. -Qiaobing > > R > > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue May 6 16:32:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07432 for ; Tue, 6 May 2003 16:32:25 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h46Kf2v26631 for tsvwg-archive@odin.ietf.org; Tue, 6 May 2003 16:41:03 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46Kdm826389; Tue, 6 May 2003 16:39:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46KWf825118 for ; Tue, 6 May 2003 16:32:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07086; Tue, 6 May 2003 16:23:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D90L-00022r-00; Tue, 06 May 2003 16:25:37 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by ietf-mx with esmtp (Exim 4.12) id 19D90L-00022n-00; Tue, 06 May 2003 16:25:37 -0400 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h46KBpxI012028; Tue, 6 May 2003 13:11:51 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AGW81127; Tue, 6 May 2003 13:11:50 -0700 (PDT) Message-ID: <3EB81704.7000904@cisco.com> Date: Tue, 06 May 2003 15:11:48 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3) Gecko/20030502 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Qiaobing Xie CC: Sellar@az33exr01.mot.com, Ronnie , "'bidulock@openss7.org'" , =?ISO-8859-1?Q?Michael_T=FCxen?= , tsvwg@ietf.org, "Sctp-Impl (E-mail)" , "Phillip T. Conrad" , "Michael A. Ramalho" References: <797470E884C6D611B7A500B0D0AA56D04426F4@batistuta.spider.com> <3EB7A31A.3020500@cisco.com> <3EB7EDFD.97CAA0CC@motorola.com> In-Reply-To: <3EB7EDFD.97CAA0CC@motorola.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Tsvwg] Re: PR-SCTP question. Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dear all: I have made what I think are the appropriate changes and I would like you all to take a look. I have put up on http://www.sctp.org under the RFC page tab A web link that will take you to a very nice diff of the 02/03 version. Please take a few moments to look at the diff's and suggest any changes I would like to get this sumbitted by Friday. R Qiaobing Xie wrote: >"Randall Stewart (cisco)" wrote: > > >>Ronnie/Brian: >> >>I think this is the correct solution... >> >>It then requires: >> >>1) A note on the receiver side .. aka handle like data .. you must start the >> sack timer etc >> >>and >> >>2) A note on the sender side.. aka you don't stop the t3-timer if there >> is no outstanding data.. and when the t3-timer goes off you should >> send a fwd-tsn as well as any retransmmitted data.. >> >>I will see if I can't cut and past from this email and do a bit >>of massaging to get the proper notes in the document.. >> >>I too view the FWD-TSN as nothing but a compressed "heres the data >>I am skipping and not sending"... >> >> > >This is indeed a good way to look at it. And I think the solution >summarized by Brian and Randy is the right approach. > >-Qiaobing > > > > >>R >> >> >> >> > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue May 6 16:32:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07508 for ; Tue, 6 May 2003 16:32:53 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h46KfVi26681 for tsvwg-archive@odin.ietf.org; Tue, 6 May 2003 16:41:31 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46KeO826570; Tue, 6 May 2003 16:40:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46K40822764 for ; Tue, 6 May 2003 16:04:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06143; Tue, 6 May 2003 15:54:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D8YZ-0001oG-00; Tue, 06 May 2003 15:56:55 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by ietf-mx with esmtp (Exim 4.12) id 19D8YY-0001nr-00; Tue, 06 May 2003 15:56:54 -0400 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h46JhLxI026902; Tue, 6 May 2003 12:43:21 -0700 (PDT) Received: from cisco.com (sjc-vpn4-351.cisco.com [10.21.81.95]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AGW76644; Tue, 6 May 2003 12:43:05 -0700 (PDT) Message-ID: <3EB81046.95EC129A@cisco.com> Date: Tue, 06 May 2003 14:43:02 -0500 From: Peter Lei X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Qiaobing Xie CC: Randall Stewart (cisco) , Sellar@il06exr01.mot.com, Ronnie , "'bidulock@openss7.org'" , Michael =?iso-8859-1?Q?T=FCxen?= , tsvwg@ietf.org, Sctp-Impl (E-mail) , "Phillip T. Conrad" , "Michael A. Ramalho" References: <797470E884C6D611B7A500B0D0AA56D04426F4@batistuta.spider.com> <3EB7A31A.3020500@cisco.com> <3EB7EDFD.97CAA0CC@motorola.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Tsvwg] Re: PR-SCTP question. Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Qiaobing Xie wrote: > > "Randall Stewart (cisco)" wrote: > > > > Ronnie/Brian: > > > > I think this is the correct solution... > > > > It then requires: > > > > 1) A note on the receiver side .. aka handle like data .. you must start the > > sack timer etc > > > > and > > > > 2) A note on the sender side.. aka you don't stop the t3-timer if there > > is no outstanding data.. and when the t3-timer goes off you should > > send a fwd-tsn as well as any retransmmitted data.. > > > > I will see if I can't cut and past from this email and do a bit > > of massaging to get the proper notes in the document.. > > > > I too view the FWD-TSN as nothing but a compressed "heres the data > > I am skipping and not sending"... > > This is indeed a good way to look at it. And I think the solution > summarized by Brian and Randy is the right approach. > > -Qiaobing Looks like the right (and straight-forware) solution to me as well... --peter > > > > R > > > > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue May 6 16:32:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07529 for ; Tue, 6 May 2003 16:32:56 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h46KfXa26694 for tsvwg-archive@odin.ietf.org; Tue, 6 May 2003 16:41:33 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46KeD826495; Tue, 6 May 2003 16:40:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SKFp809460 for ; Mon, 28 Apr 2003 16:15:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13226 for ; Mon, 28 Apr 2003 16:10:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AEzb-00057c-00 for tsvwg@ietf.org; Mon, 28 Apr 2003 16:12:51 -0400 Received: from [129.46.75.149] (helo=maggie.ka9q.net) by ietf-mx with esmtp (Exim 4.12) id 19AEzb-00057Z-00 for tsvwg@ietf.org; Mon, 28 Apr 2003 16:12:51 -0400 Received: from [127.0.0.1] (helo=qualcomm.com) by maggie.ka9q.net with esmtp (Exim 3.35 #1 (Debian)) id 19AF09-0000gD-00; Mon, 28 Apr 2003 13:13:25 -0700 Message-ID: <3EAD8B64.40308@qualcomm.com> Date: Mon, 28 Apr 2003 13:13:24 -0700 From: Phil Karn User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en MIME-Version: 1.0 To: Reiner Ludwig CC: tsvwg@ietf.org Subject: Re: [Tsvwg] Re: Rethinking Karn's algorithm References: <5.1.0.14.0.20030325221003.00aa6300@mailhost.eed.ericsson.se> <5.1.0.14.0.20030325221003.00aa6300@mailhost.eed.ericsson.se> <5.2.0.9.0.20030428151415.025d2b28@mailhost.eed.ericsson.se> In-Reply-To: <5.2.0.9.0.20030428151415.025d2b28@mailhost.eed.ericsson.se> X-Enigmail-Version: 0.74.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Reiner Ludwig wrote: > A different question that was discussed before on the list is the > exponential backoff; up to ~60 seconds. Don't you think that that is a > bit too conservative? Well, I have seen some router queues that get amazingly long... Phil _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue May 6 16:32:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07546 for ; Tue, 6 May 2003 16:32:57 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h46KfYm26708 for tsvwg-archive@odin.ietf.org; Tue, 6 May 2003 16:41:34 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46KeH826525; Tue, 6 May 2003 16:40:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4682c828564 for ; Tue, 6 May 2003 04:02:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11101 for ; Tue, 6 May 2003 03:53:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CxIk-00047A-00 for tsvwg@ietf.org; Tue, 06 May 2003 03:55:50 -0400 Received: from mail-n.franken.de ([193.175.24.27] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 19CxIe-00046i-00 for tsvwg@ietf.org; Tue, 06 May 2003 03:55:45 -0400 Received: from fh-muenster.de (fb02np06.FH-Muenster.DE [194.95.73.131]) by mail-n.franken.de (Postfix) with ESMTP id 5F067245D2; Tue, 6 May 2003 09:55:50 +0200 (CEST) Date: Tue, 6 May 2003 09:54:51 +0200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Randall Stewart (cisco)" , tsvwg@ietf.org, "Sellar, Ronnie" , "Sctp-Impl (E-mail)" , "Phillip T. Conrad" , Qiaobing Xie , "Michael A. Ramalho" To: bidulock@openss7.org From: =?ISO-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <20030505123424.B23984@openss7.org> Message-Id: <04285F65-7F98-11D7-B5AF-0030654C1AB6@fh-muenster.de> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4682c828578 Subject: [Tsvwg] Re: PR-SCTP question. Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi all, Brians solution handles the case at the end of live of an association. Consider this case: A sends TSN 0,1,2 on stream 0, all ordered. TSN 0 gets dropped in the network. TSN 1 and TSN 2 arrive and get SACKed. Now the sender drops (in the sense of PR-SCTP) TSN 0 and sends a FWD-TSN chunk which is dropped in the network. The sender now has no timers running, the receiver waits for TSN 0 to deliver TSN 1 and TSN 2 to the upper layer. This situation is not changed until the Upper Layer on the sender side decides to send more data or initiates the shutdown procedure. Did I miss something? Best regards Michael On Monday, May 5, 2003, at 20:34 Europe/Berlin, Brian F. G. Bidulock wrote: > Randall, > > If the FWD-TSN is treated in the same fashion as DATA is in the > base protocol with regard to the sending of SACK, in this case a > SACK would already be required by the base protocol would it > not? So I don't think that there is a need for an alteration in > SACK processing. IHO the problem appears to be (as you allude) > that for a normal DATA transmission there is a retransmit timer > running whereas for FWD-TSN there is not. During normal data > transmission during the association, this is not problematic > because of the rules for sending subsequent FWD-TSN in receipt > of SACK. It is only in this case where there is no further data > to send. > > As this only appears to be a problem in this one situation (not > subsequent DATA to send and no SACKs forthcoming), it might be > possible to handle this with a SHUTDOWN rule such as follows: > > Whenever the PR-SCTP sender enters the SHUTDOWN-PENDING state, > and there are only TSNs marked dropped for retransmission (for > which FWD-TSNs have been sent) a SHUTDOWN chunk is sent and the > sender enters the SHUTDOWN-SENT state. (The same for > SHUTDOWN-RECEIVED and SHUTDOWN-ACK-SENT states.) > > Whenever the PR-SCTP receiver receives a SHUTDOWN or > SHUTDOWN-ACK and there are gaps in its received TSN sequence > (messages awaiting reordering before delivery to the user), it > will treat the SHUTDOWN or SHUTDOWN-ACK though it were a forward > TSN for all missing data chunks. > > The trick here is to not delay the SHUTDOWN (or SHUTDOWN-ACK) > chunk being sent waiting for acknowledgement of dropped TSNs > but to send it anyways with the knowledge that the receiver can > imply any missing TSNs as having been dropped. > > I think this would better meet the intent of PR-SCTP (and in > particular timed-reliability) as it does not rely on a timer to > arrive at the implication of a missed FWD-TSN. The receipt of a > SHUTDOWN or SHUTDOWN-ACK can be treated as an implied FWD-TSN > for all outstanding data. > > Under the base protocol, what happens if a sender sends a > SHUTDOWN chunk *before* all its sent data is acknowledged? I > think an implementation could either complete the shutdown and > discard data awaiting reordering, or ABORT the association. For > PR-SCTP, receiving SHUTDOWN early could be construed as cause to > mark as dropped all outstanding data, and move the cummulative > ack point to the "highest" received TSN and complete the > SHUTDOWN procedure. > > Does that make sense? > > So effectively the rules would be that a SHUTDOWN or > SHUTDOWN-ACK should not be delayed in the SHUTDOWN-PENDING or > SHUTDOWN-RECEIVED states solely on the basis of unacknowledged > but "dropped" TSNs, and that a received SHUTDOWN or SHUTDOWN-ACK > chunk that is otherwise valid should be construed by the > receiver to have the same effect as a FWD-TSN dropping all > outstanding TSNs. > > Is that simpler than a timer? > > --brian > > > Whenever the receiver receives > > > On Mon, 05 May 2003, Randall Stewart (cisco) wrote: > >> Ronnie: >> >> Nope, I don't think you are missing anything. I have been testing the >> internal Cisco-IOS implementation of PR-SCTP against the KAME stack >> and have reached the same conclusion. I think we need to require that >> the >> receiver of a FWD-TSN send a SACK in reponse to this. Otherwise >> you have this deadlock scenario.... I have made the KAME stack >> send the SACK.. but this then begs another question... >> >> If the SACK in the return path was lost (I am testing at times with >> error rates set to 20%... so that happens a lot).. what do we do? >> >> It almost sounds like we need not only to require a FWD-TSN get >> a SACK in response.. but that the sender of the FWD-TSN, if no >> other data is being sent, start a timer to retransmit the FWD-TSN >> if no SACK is received.. not sure if I worded that clear but I think >> it will be needed... >> >> Co-authors.. what do you-all think? >> >> R >> >> >> Sellar, Ronnie wrote: >> >>> Hi, >>> >>> We have just started looking at PR-SCTP with a view to having a >>> prototype >>> implementation ready for the next Interop in Delaware and have come >>> up with >>> a question regarding the FORWARD-TSN chunk and how it could affect >>> association termination. >>> >>> Consider the following example. Endpoint A has an association with >>> endpoint >>> B in which all the data it sends is ordered and marked as >>> 'unreliable' for >>> whatever reason. Endpoint A has now sent all the data it wants to >>> send to B >>> but can't yet close the association because B has not yet >>> acknowledged one >>> of the TSNs. Lets say that it has transmitted TSNs 1-100 but has >>> not yet >>> received an acknowledgement of TSN 97 since B has not yet received >>> that TSN. >>> >>> In this situation A cannot yet send the SHUTDOWN since not all data >>> is acked >>> and B has three chunks it cannot deliver to it's user (98, 99 and >>> 100) since >>> it has not received 97. When A receives the last SACK it decides >>> that it no >>> longer wants to retransmit chunk 97 and so issues a FORWARD-TSN >>> chunk to >>> move the cumulative ack TSN on to 100. How does A know that B >>> received the >>> FORWARD-TSN chunk ? There is no more data to send so B will not be >>> sending >>> any more SACKs. If B sends no more SACKs A's cumulative ack TSN >>> will not >>> advance and so he will not be able to send the SHUTDOWN chunk. >>> >>> In B's case when he receives the FORWARD-TSN he will be happy, >>> deliver >>> 98-100 to the user and move his cumulative TSN forward. But he is >>> not >>> required to send a SACK to tell A he has done so. Are we now in a >>> stalemate >>> situation ? >>> >>> Also consider the case where B never receives the FORWARD-TSN. He >>> is now >>> stuck with 98-100 in his buffers which he cannot deliver since he >>> doesn't >>> know that 97 is not coming. Have we reached a similar stalemate ? >>> >>> Perhaps I'm missing something, but I do think there seems to be a >>> problem if >>> a FORWARD-TSN chunk is the last chunk to be transmitted on an >>> association. >>> Please feel free to correct me if I'm wrong. >>> >>> Cheers >>> >>> Ronnie >>> >>> --- >>> Ronnie Sellar Artesyn Communications Products >>> Tel: +44 131 475 7015 Suite 4, 2 Anderson Place >>> Fax: +44 131 475 7001 Edinburgh EH6 5NP >>> mailto:ronnie@artesyncp.com http://www.artesyncp.com >>> >>> >>> >> >> >> -- >> Randall R. Stewart >> ITD >> Cisco Systems Inc. >> rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) >> > > -- > Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ > bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ > http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ > ¦ Therefore all progress depends on the ¦ > ¦ unreasonable man. -- George Bernard Shaw ¦ > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue May 6 16:33:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07561 for ; Tue, 6 May 2003 16:33:04 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h46KffU26722 for tsvwg-archive@odin.ietf.org; Tue, 6 May 2003 16:41:41 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46KeF826510; Tue, 6 May 2003 16:40:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h467FL821867 for ; Tue, 6 May 2003 03:15:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10217 for ; Tue, 6 May 2003 03:06:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CwYm-0003rK-00 for tsvwg@ietf.org; Tue, 06 May 2003 03:08:20 -0400 Received: from [194.217.109.12] (helo=bifrost.spider.com) by ietf-mx with smtp (Exim 4.12) id 19CwYe-0003rD-00 for tsvwg@ietf.org; Tue, 06 May 2003 03:08:14 -0400 Received: from no.name.available by bifrost.spider.com via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; 6 May 2003 07:08:47 UT Received: from heimdall-dmz.spider.com (batistuta.spider.com [212.240.99.13]) by caly80.spider.com (Postfix) with SMTP id 15D786F5C; Tue, 6 May 2003 08:04:32 +0100 (BST) Received: from batistuta.spider.com by heimdall-dmz.spider.com via smtpd (for [172.16.254.22]) with SMTP; 6 May 2003 07:08:40 UT Received: by batistuta.spider.com with Internet Mail Service (5.5.2653.19) id ; Tue, 6 May 2003 08:05:53 +0100 Message-ID: <797470E884C6D611B7A500B0D0AA56D04426F2@batistuta.spider.com> From: "Sellar, Ronnie" To: "'Randall Stewart (cisco)'" , bidulock@openss7.org Cc: tsvwg@ietf.org, "Sellar, Ronnie" , "Sctp-Impl (E-mail)" , "Phillip T. Conrad" , Qiaobing Xie , =?iso-8859-1?Q?Michael_T=FCxen?= , "Michael A. Ramalho" Date: Tue, 6 May 2003 08:05:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h467I1822038 Subject: [Tsvwg] RE: PR-SCTP question. Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi, Sending a SHUTDOWN or SHUTDOWN-ACK when all your data has been acked or abandoned was the best solution we came up with. We did realise that this would mean some change to SHUTDOWN/SHUTDOWN-ACK processing for a PR-SCTP implementation. We also thought it would be a good idea to raise this now so that any solution could be tested in Delaware. So do we go ahead and code 1) and 2) in Randall's e-mail or do we have to wait for some agreement from the authors ? Thanks for your replies. Ronnie --- Ronnie Sellar Artesyn Communications Products Tel: +44 131 475 7015 Suite 4, 2 Anderson Place Fax: +44 131 475 7001 Edinburgh EH6 5NP mailto:ronnie@artesyncp.com http://www.artesyncp.com > -----Original Message----- > From: Randall Stewart (cisco) [mailto:rrs@cisco.com] > Sent: 05 May 2003 19:46 > To: bidulock@openss7.org > Cc: tsvwg@ietf.org; Sellar, Ronnie; Sctp-Impl (E-mail); Phillip T. > Conrad; Qiaobing Xie; Michael Tüxen; Michael A. Ramalho > Subject: Re: PR-SCTP question. > > > Brian: > > Seems like a much better solution than having a timer.. > > so we end up with: > > 1) A note in PR-SCTP about the SHUTDOWN cases as you mention. > > 2) A note in PR-SCTP regarding SACK's aka a FWD-TSN MUST be > treated as a DATA chunk in regard to sending SACK's ( I think > this is needed since there is no mention to it in the document > currently). > > R > > > Brian F. G. Bidulock wrote: > > >Randall, > > > >If the FWD-TSN is treated in the same fashion as DATA is in the > >base protocol with regard to the sending of SACK, in this case a > >SACK would already be required by the base protocol would it > >not? So I don't think that there is a need for an alteration in > >SACK processing. IHO the problem appears to be (as you allude) > >that for a normal DATA transmission there is a retransmit timer > >running whereas for FWD-TSN there is not. During normal data > >transmission during the association, this is not problematic > >because of the rules for sending subsequent FWD-TSN in receipt > >of SACK. It is only in this case where there is no further data > >to send. > > > >As this only appears to be a problem in this one situation (not > >subsequent DATA to send and no SACKs forthcoming), it might be > >possible to handle this with a SHUTDOWN rule such as follows: > > > >Whenever the PR-SCTP sender enters the SHUTDOWN-PENDING state, > >and there are only TSNs marked dropped for retransmission (for > >which FWD-TSNs have been sent) a SHUTDOWN chunk is sent and the > >sender enters the SHUTDOWN-SENT state. (The same for > >SHUTDOWN-RECEIVED and SHUTDOWN-ACK-SENT states.) > > > >Whenever the PR-SCTP receiver receives a SHUTDOWN or > >SHUTDOWN-ACK and there are gaps in its received TSN sequence > >(messages awaiting reordering before delivery to the user), it > >will treat the SHUTDOWN or SHUTDOWN-ACK though it were a forward > >TSN for all missing data chunks. > > > >The trick here is to not delay the SHUTDOWN (or SHUTDOWN-ACK) > >chunk being sent waiting for acknowledgement of dropped TSNs > >but to send it anyways with the knowledge that the receiver can > >imply any missing TSNs as having been dropped. > > > >I think this would better meet the intent of PR-SCTP (and in > >particular timed-reliability) as it does not rely on a timer to > >arrive at the implication of a missed FWD-TSN. The receipt of a > >SHUTDOWN or SHUTDOWN-ACK can be treated as an implied FWD-TSN > >for all outstanding data. > > > >Under the base protocol, what happens if a sender sends a > >SHUTDOWN chunk *before* all its sent data is acknowledged? I > >think an implementation could either complete the shutdown and > >discard data awaiting reordering, or ABORT the association. For > >PR-SCTP, receiving SHUTDOWN early could be construed as cause to > >mark as dropped all outstanding data, and move the cummulative > >ack point to the "highest" received TSN and complete the > >SHUTDOWN procedure. > > > >Does that make sense? > > > >So effectively the rules would be that a SHUTDOWN or > >SHUTDOWN-ACK should not be delayed in the SHUTDOWN-PENDING or > >SHUTDOWN-RECEIVED states solely on the basis of unacknowledged > >but "dropped" TSNs, and that a received SHUTDOWN or SHUTDOWN-ACK > >chunk that is otherwise valid should be construed by the > >receiver to have the same effect as a FWD-TSN dropping all > >outstanding TSNs. > > > >Is that simpler than a timer? > > > >--brian > > > > > >Whenever the receiver receives > > > > > >On Mon, 05 May 2003, Randall Stewart (cisco) wrote: > > > > > > > >>Ronnie: > >> > >>Nope, I don't think you are missing anything. I have been > testing the > >>internal Cisco-IOS implementation of PR-SCTP against the KAME stack > >>and have reached the same conclusion. I think we need to > require that the > >>receiver of a FWD-TSN send a SACK in reponse to this. Otherwise > >>you have this deadlock scenario.... I have made the KAME stack > >>send the SACK.. but this then begs another question... > >> > >>If the SACK in the return path was lost (I am testing at times with > >>error rates set to 20%... so that happens a lot).. what do we do? > >> > >>It almost sounds like we need not only to require a FWD-TSN get > >>a SACK in response.. but that the sender of the FWD-TSN, if no > >>other data is being sent, start a timer to retransmit the FWD-TSN > >>if no SACK is received.. not sure if I worded that clear but I think > >>it will be needed... > >> > >>Co-authors.. what do you-all think? > >> > >>R > >> > >> > >>Sellar, Ronnie wrote: > >> > >> > >> > >>>Hi, > >>> > >>>We have just started looking at PR-SCTP with a view to > having a prototype > >>>implementation ready for the next Interop in Delaware and > have come up with > >>>a question regarding the FORWARD-TSN chunk and how it could affect > >>>association termination. > >>> > >>>Consider the following example. Endpoint A has an > association with endpoint > >>>B in which all the data it sends is ordered and marked as > 'unreliable' for > >>>whatever reason. Endpoint A has now sent all the data it > wants to send to B > >>>but can't yet close the association because B has not yet > acknowledged one > >>>of the TSNs. Lets say that it has transmitted TSNs 1-100 > but has not yet > >>>received an acknowledgement of TSN 97 since B has not yet > received that TSN. > >>> > >>>In this situation A cannot yet send the SHUTDOWN since not > all data is acked > >>>and B has three chunks it cannot deliver to it's user (98, > 99 and 100) since > >>>it has not received 97. When A receives the last SACK it > decides that it no > >>>longer wants to retransmit chunk 97 and so issues a > FORWARD-TSN chunk to > >>>move the cumulative ack TSN on to 100. How does A know > that B received the > >>>FORWARD-TSN chunk ? There is no more data to send so B > will not be sending > >>>any more SACKs. If B sends no more SACKs A's cumulative > ack TSN will not > >>>advance and so he will not be able to send the SHUTDOWN chunk. > >>> > >>>In B's case when he receives the FORWARD-TSN he will be > happy, deliver > >>>98-100 to the user and move his cumulative TSN forward. > But he is not > >>>required to send a SACK to tell A he has done so. Are we > now in a stalemate > >>>situation ? > >>> > >>>Also consider the case where B never receives the > FORWARD-TSN. He is now > >>>stuck with 98-100 in his buffers which he cannot deliver > since he doesn't > >>>know that 97 is not coming. Have we reached a similar stalemate ? > >>> > >>>Perhaps I'm missing something, but I do think there seems > to be a problem if > >>>a FORWARD-TSN chunk is the last chunk to be transmitted on > an association. > >>>Please feel free to correct me if I'm wrong. > >>> > >>>Cheers > >>> > >>>Ronnie > >>> > >>>--- > >>>Ronnie Sellar Artesyn Communications Products > >>>Tel: +44 131 475 7015 Suite 4, 2 Anderson Place > >>>Fax: +44 131 475 7001 Edinburgh EH6 5NP > >>>mailto:ronnie@artesyncp.com http://www.artesyncp.com > >>> > >>> > >>> > >>> > >>> > >>-- > >>Randall R. Stewart > >>ITD > >>Cisco Systems Inc. > >>rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) > >> > >> > >> > > > > > > > > > -- > Randall R. Stewart > ITD > Cisco Systems Inc. > rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) > > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue May 6 16:33:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07575 for ; Tue, 6 May 2003 16:33:07 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h46Kfic26737 for tsvwg-archive@odin.ietf.org; Tue, 6 May 2003 16:41:44 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46KeL826555; Tue, 6 May 2003 16:40:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46CRT817450 for ; Tue, 6 May 2003 08:27:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17028 for ; Tue, 6 May 2003 08:18:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D1Qi-0005YE-00 for tsvwg@ietf.org; Tue, 06 May 2003 08:20:20 -0400 Received: from mail-n.franken.de ([193.175.24.27] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 19D1Qc-0005Xs-00 for tsvwg@ietf.org; Tue, 06 May 2003 08:20:14 -0400 Received: from micmac.franken.de (fb02np06.FH-Muenster.DE [194.95.73.131]) by mail-n.franken.de (Postfix) with ESMTP id 2DCC0245D2; Tue, 6 May 2003 14:20:30 +0200 (CEST) Date: Tue, 6 May 2003 14:19:29 +0200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Randall Stewart (cisco)" , tsvwg@ietf.org, "Sellar, Ronnie" , "Sctp-Impl (E-mail)" , "Phillip T. Conrad" , Qiaobing Xie , "Michael A. Ramalho" To: bidulock@openss7.org From: =?ISO-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <20030506030405.A7706@openss7.org> Message-Id: X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h46CSE817532 Subject: [Tsvwg] Re: PR-SCTP question. Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Brian, sending a FWD-TSN chunk is from a SACK point of view equivalent to sending DATA chunks. That means that the timer handling should be the same for FWD-TSN and for DATA. In my example this would mean that you transmit the FWD-TSN chunk due to a T3_RTX timer event and you have to restart it. You do not need a new timer, but you have to start one and using T3_RTX is the one with the already defined procedures. So you should use that. Best regards Michael On Tuesday, May 6, 2003, at 11:04 Europe/Berlin, Brian F. G. Bidulock wrote: > Michael, > > Yes, I was thinking there might be a problem during transmission too. > > However, as t3-rtx is never running in this circumstance, yet the > sender > of the FWD-TSN can indeed expect a SACK within an RTO for the FWD-TSN. > > So, it would be possible to borrow the t3-rtx timer (rather than adding > a new one) to solve this siutation as follows: > > When the sender sends a FWD-TSN and there is no unacknowledged data > remaining, resulting from the dropped TSNs, that t3-rtx SHOULD NOT be > stopped. This would be an alteration to rule A2). > > In addition, when the t3-trx timer expires, normal base protocol > retransmission would occur and, in addition, if the cummulative TSN ack > point is less than the Advanced.Peer.Ack.Point that in addition to > normal retransmission a FWD-TSN be bundled with any retransmitted DATA > chunks indicating the Advanced.Peer.Ack.Point (again) to the receiver. > This would be an additional rule, say A4. > > That is, one could make retransmission of the FWD-TSN subject to the > same rules as would have applied to the DATA had it not been dropped. > > Coupled this with making the FWD-TSN at the receiver subject to the > same > rules visa vi SACK as the received DATA would have been subject. (This > would also be an addition as Randall notes.) > > Then all cases of retransmission of FWD-TSN would be handled in the > same > fashion as the base protocol and none of these problems can any longer > ensue. Modifications to SHUTDOWN would then no longer be required. > Also, no additional timers would be required. > > One can then think of the FWD-TSN as a compressed placeholder for the > DATA that was dropped. If the place holder is subject to the same > retramission (t3-rtx) and acknowledgement (SACK) rules as the DATA it > represents, then the only variation from the base protocol is that the > data itself does not need to be retransmitted once expired, and the > place holders for a number of DATA chunks can be represented in a > single > FWD-TSN. > > I think the change would be minor in implementation (not stop T3-rtx > when only dropped data is outstanding and consider retransmission of > FWD-TSN when considering DATA for retransmission). > > Note that the SHUTDOWN case is also handled (because now the FWD-TSN > for > the dropped TSN 97 would be retransmitted on T3-rtx, and T3-rtx would > be > restarted, retransmission pegs counted, ... just as though the data > for > TSN 97 were being retransmitted.) > > How does that sound? > > Is that a better and more complete solution proposal? > > --brian > > On Tue, 06 May 2003, Michael Tüxen wrote: > >> Hi all, >> >> Brians solution handles the case at the end of live of an association. >> >> Consider this case: >> >> A sends TSN 0,1,2 on stream 0, all ordered. TSN 0 gets dropped in the >> network. >> TSN 1 and TSN 2 arrive and get SACKed. Now the sender drops (in the >> sense of >> PR-SCTP) TSN 0 and sends a FWD-TSN chunk which is dropped in the >> network. >> The sender now has no timers running, the receiver waits for TSN 0 to >> deliver >> TSN 1 and TSN 2 to the upper layer. >> >> This situation is not changed until the Upper Layer on the sender side >> decides >> to send more data or initiates the shutdown procedure. >> >> Did I miss something? >> >> Best regards >> Michael >> >> On Monday, May 5, 2003, at 20:34 Europe/Berlin, Brian F. G. Bidulock >> wrote: >> >>> Randall, >>> >>> If the FWD-TSN is treated in the same fashion as DATA is in the >>> base protocol with regard to the sending of SACK, in this case a >>> SACK would already be required by the base protocol would it >>> not? So I don't think that there is a need for an alteration in >>> SACK processing. IHO the problem appears to be (as you allude) >>> that for a normal DATA transmission there is a retransmit timer >>> running whereas for FWD-TSN there is not. During normal data >>> transmission during the association, this is not problematic >>> because of the rules for sending subsequent FWD-TSN in receipt >>> of SACK. It is only in this case where there is no further data >>> to send. >>> >>> As this only appears to be a problem in this one situation (not >>> subsequent DATA to send and no SACKs forthcoming), it might be >>> possible to handle this with a SHUTDOWN rule such as follows: >>> >>> Whenever the PR-SCTP sender enters the SHUTDOWN-PENDING state, >>> and there are only TSNs marked dropped for retransmission (for >>> which FWD-TSNs have been sent) a SHUTDOWN chunk is sent and the >>> sender enters the SHUTDOWN-SENT state. (The same for >>> SHUTDOWN-RECEIVED and SHUTDOWN-ACK-SENT states.) >>> >>> Whenever the PR-SCTP receiver receives a SHUTDOWN or >>> SHUTDOWN-ACK and there are gaps in its received TSN sequence >>> (messages awaiting reordering before delivery to the user), it >>> will treat the SHUTDOWN or SHUTDOWN-ACK though it were a forward >>> TSN for all missing data chunks. >>> >>> The trick here is to not delay the SHUTDOWN (or SHUTDOWN-ACK) >>> chunk being sent waiting for acknowledgement of dropped TSNs >>> but to send it anyways with the knowledge that the receiver can >>> imply any missing TSNs as having been dropped. >>> >>> I think this would better meet the intent of PR-SCTP (and in >>> particular timed-reliability) as it does not rely on a timer to >>> arrive at the implication of a missed FWD-TSN. The receipt of a >>> SHUTDOWN or SHUTDOWN-ACK can be treated as an implied FWD-TSN >>> for all outstanding data. >>> >>> Under the base protocol, what happens if a sender sends a >>> SHUTDOWN chunk *before* all its sent data is acknowledged? I >>> think an implementation could either complete the shutdown and >>> discard data awaiting reordering, or ABORT the association. For >>> PR-SCTP, receiving SHUTDOWN early could be construed as cause to >>> mark as dropped all outstanding data, and move the cummulative >>> ack point to the "highest" received TSN and complete the >>> SHUTDOWN procedure. >>> >>> Does that make sense? >>> >>> So effectively the rules would be that a SHUTDOWN or >>> SHUTDOWN-ACK should not be delayed in the SHUTDOWN-PENDING or >>> SHUTDOWN-RECEIVED states solely on the basis of unacknowledged >>> but "dropped" TSNs, and that a received SHUTDOWN or SHUTDOWN-ACK >>> chunk that is otherwise valid should be construed by the >>> receiver to have the same effect as a FWD-TSN dropping all >>> outstanding TSNs. >>> >>> Is that simpler than a timer? >>> >>> --brian >>> >>> >>> Whenever the receiver receives >>> >>> >>> On Mon, 05 May 2003, Randall Stewart (cisco) wrote: >>> >>>> Ronnie: >>>> >>>> Nope, I don't think you are missing anything. I have been testing >>>> the >>>> internal Cisco-IOS implementation of PR-SCTP against the KAME stack >>>> and have reached the same conclusion. I think we need to require >>>> that >>>> the >>>> receiver of a FWD-TSN send a SACK in reponse to this. Otherwise >>>> you have this deadlock scenario.... I have made the KAME stack >>>> send the SACK.. but this then begs another question... >>>> >>>> If the SACK in the return path was lost (I am testing at times with >>>> error rates set to 20%... so that happens a lot).. what do we do? >>>> >>>> It almost sounds like we need not only to require a FWD-TSN get >>>> a SACK in response.. but that the sender of the FWD-TSN, if no >>>> other data is being sent, start a timer to retransmit the FWD-TSN >>>> if no SACK is received.. not sure if I worded that clear but I think >>>> it will be needed... >>>> >>>> Co-authors.. what do you-all think? >>>> >>>> R >>>> >>>> >>>> Sellar, Ronnie wrote: >>>> >>>>> Hi, >>>>> >>>>> We have just started looking at PR-SCTP with a view to having a >>>>> prototype >>>>> implementation ready for the next Interop in Delaware and have come >>>>> up with >>>>> a question regarding the FORWARD-TSN chunk and how it could affect >>>>> association termination. >>>>> >>>>> Consider the following example. Endpoint A has an association with >>>>> endpoint >>>>> B in which all the data it sends is ordered and marked as >>>>> 'unreliable' for >>>>> whatever reason. Endpoint A has now sent all the data it wants to >>>>> send to B >>>>> but can't yet close the association because B has not yet >>>>> acknowledged one >>>>> of the TSNs. Lets say that it has transmitted TSNs 1-100 but has >>>>> not yet >>>>> received an acknowledgement of TSN 97 since B has not yet received >>>>> that TSN. >>>>> >>>>> In this situation A cannot yet send the SHUTDOWN since not all data >>>>> is acked >>>>> and B has three chunks it cannot deliver to it's user (98, 99 and >>>>> 100) since >>>>> it has not received 97. When A receives the last SACK it decides >>>>> that it no >>>>> longer wants to retransmit chunk 97 and so issues a FORWARD-TSN >>>>> chunk to >>>>> move the cumulative ack TSN on to 100. How does A know that B >>>>> received the >>>>> FORWARD-TSN chunk ? There is no more data to send so B will not be >>>>> sending >>>>> any more SACKs. If B sends no more SACKs A's cumulative ack TSN >>>>> will not >>>>> advance and so he will not be able to send the SHUTDOWN chunk. >>>>> >>>>> In B's case when he receives the FORWARD-TSN he will be happy, >>>>> deliver >>>>> 98-100 to the user and move his cumulative TSN forward. But he is >>>>> not >>>>> required to send a SACK to tell A he has done so. Are we now in a >>>>> stalemate >>>>> situation ? >>>>> >>>>> Also consider the case where B never receives the FORWARD-TSN. He >>>>> is now >>>>> stuck with 98-100 in his buffers which he cannot deliver since he >>>>> doesn't >>>>> know that 97 is not coming. Have we reached a similar stalemate ? >>>>> >>>>> Perhaps I'm missing something, but I do think there seems to be a >>>>> problem if >>>>> a FORWARD-TSN chunk is the last chunk to be transmitted on an >>>>> association. >>>>> Please feel free to correct me if I'm wrong. >>>>> >>>>> Cheers >>>>> >>>>> Ronnie >>>>> >>>>> --- >>>>> Ronnie Sellar Artesyn Communications Products >>>>> Tel: +44 131 475 7015 Suite 4, 2 Anderson Place >>>>> Fax: +44 131 475 7001 Edinburgh EH6 5NP >>>>> mailto:ronnie@artesyncp.com http://www.artesyncp.com >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Randall R. Stewart >>>> ITD >>>> Cisco Systems Inc. >>>> rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) >>>> >>> >>> -- >>> Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ >>> bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ >>> http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ >>> ¦ Therefore all progress depends on the ¦ >>> ¦ unreasonable man. -- George Bernard Shaw ¦ >>> > > -- > Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ > bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ > http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ > ¦ Therefore all progress depends on the ¦ > ¦ unreasonable man. -- George Bernard Shaw ¦ > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue May 6 16:33:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07598 for ; Tue, 6 May 2003 16:33:24 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h46Kg2E26788 for tsvwg-archive@odin.ietf.org; Tue, 6 May 2003 16:42:02 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46KeJ826540; Tue, 6 May 2003 16:40:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h469ip805232 for ; Tue, 6 May 2003 05:44:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12716 for ; Tue, 6 May 2003 05:35:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Cytd-0004ZR-00 for tsvwg@ietf.org; Tue, 06 May 2003 05:38:01 -0400 Received: from [194.217.109.12] (helo=bifrost.spider.com) by ietf-mx with smtp (Exim 4.12) id 19CytX-0004ZH-00 for tsvwg@ietf.org; Tue, 06 May 2003 05:37:56 -0400 Received: from no.name.available by bifrost.spider.com via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; 6 May 2003 09:38:31 UT Received: from heimdall-dmz.spider.com (batistuta.spider.com [212.240.99.13]) by caly80.spider.com (Postfix) with SMTP id 539546F81; Tue, 6 May 2003 10:34:07 +0100 (BST) Received: from batistuta.spider.com by heimdall-dmz.spider.com via smtpd (for [172.16.254.22]) with SMTP; 6 May 2003 09:38:15 UT Received: by batistuta.spider.com with Internet Mail Service (5.5.2653.19) id ; Tue, 6 May 2003 10:35:29 +0100 Message-ID: <797470E884C6D611B7A500B0D0AA56D04426F4@batistuta.spider.com> From: "Sellar, Ronnie" To: "'bidulock@openss7.org'" , =?iso-8859-1?Q?Michael_T=FCxen?= Cc: "Randall Stewart (cisco)" , tsvwg@ietf.org, "Sellar, Ronnie" , "Sctp-Impl (E-mail)" , "Phillip T. Conrad" , Qiaobing Xie , "Michael A. Ramalho" Date: Tue, 6 May 2003 10:35:28 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h469ip805233 Subject: [Tsvwg] RE: PR-SCTP question. Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Brian, This does sound a better solution to me. It means that SHUTDOWN/SHUTDOWN-ACK processing is not affected and it also fixes Michael's problem of stuck data in the middle of an association. Regards Ronnie --- Ronnie Sellar Artesyn Communications Products Tel: +44 131 475 7015 Suite 4, 2 Anderson Place Fax: +44 131 475 7001 Edinburgh EH6 5NP mailto:ronnie@artesyncp.com http://www.artesyncp.com > -----Original Message----- > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > Sent: 06 May 2003 10:04 > To: Michael Tüxen > Cc: Randall Stewart (cisco); tsvwg@ietf.org; Sellar, Ronnie; Sctp-Impl > (E-mail); Phillip T. Conrad; Qiaobing Xie; Michael A. Ramalho > Subject: Re: PR-SCTP question. > > > Michael, > > Yes, I was thinking there might be a problem during transmission too. > > However, as t3-rtx is never running in this circumstance, yet > the sender > of the FWD-TSN can indeed expect a SACK within an RTO for the FWD-TSN. > > So, it would be possible to borrow the t3-rtx timer (rather > than adding > a new one) to solve this siutation as follows: > > When the sender sends a FWD-TSN and there is no unacknowledged data > remaining, resulting from the dropped TSNs, that t3-rtx SHOULD NOT be > stopped. This would be an alteration to rule A2). > > In addition, when the t3-trx timer expires, normal base protocol > retransmission would occur and, in addition, if the > cummulative TSN ack > point is less than the Advanced.Peer.Ack.Point that in addition to > normal retransmission a FWD-TSN be bundled with any retransmitted DATA > chunks indicating the Advanced.Peer.Ack.Point (again) to the receiver. > This would be an additional rule, say A4. > > That is, one could make retransmission of the FWD-TSN subject to the > same rules as would have applied to the DATA had it not been dropped. > > Coupled this with making the FWD-TSN at the receiver subject > to the same > rules visa vi SACK as the received DATA would have been > subject. (This > would also be an addition as Randall notes.) > > Then all cases of retransmission of FWD-TSN would be handled > in the same > fashion as the base protocol and none of these problems can any longer > ensue. Modifications to SHUTDOWN would then no longer be required. > Also, no additional timers would be required. > > One can then think of the FWD-TSN as a compressed placeholder for the > DATA that was dropped. If the place holder is subject to the same > retramission (t3-rtx) and acknowledgement (SACK) rules as the DATA it > represents, then the only variation from the base protocol is that the > data itself does not need to be retransmitted once expired, and the > place holders for a number of DATA chunks can be represented > in a single > FWD-TSN. > > I think the change would be minor in implementation (not stop T3-rtx > when only dropped data is outstanding and consider retransmission of > FWD-TSN when considering DATA for retransmission). > > Note that the SHUTDOWN case is also handled (because now the > FWD-TSN for > the dropped TSN 97 would be retransmitted on T3-rtx, and > T3-rtx would be > restarted, retransmission pegs counted, ... just as though > the data for > TSN 97 were being retransmitted.) > > How does that sound? > > Is that a better and more complete solution proposal? > > --brian > > On Tue, 06 May 2003, Michael Tüxen wrote: > > > Hi all, > > > > Brians solution handles the case at the end of live of an > association. > > > > Consider this case: > > > > A sends TSN 0,1,2 on stream 0, all ordered. TSN 0 gets > dropped in the > > network. > > TSN 1 and TSN 2 arrive and get SACKed. Now the sender drops (in the > > sense of > > PR-SCTP) TSN 0 and sends a FWD-TSN chunk which is dropped in the > > network. > > The sender now has no timers running, the receiver waits > for TSN 0 to > > deliver > > TSN 1 and TSN 2 to the upper layer. > > > > This situation is not changed until the Upper Layer on the > sender side > > decides > > to send more data or initiates the shutdown procedure. > > > > Did I miss something? > > > > Best regards > > Michael > > > > On Monday, May 5, 2003, at 20:34 Europe/Berlin, Brian F. G. > Bidulock > > wrote: > > > > > Randall, > > > > > > If the FWD-TSN is treated in the same fashion as DATA is in the > > > base protocol with regard to the sending of SACK, in this case a > > > SACK would already be required by the base protocol would it > > > not? So I don't think that there is a need for an alteration in > > > SACK processing. IHO the problem appears to be (as you allude) > > > that for a normal DATA transmission there is a retransmit timer > > > running whereas for FWD-TSN there is not. During normal data > > > transmission during the association, this is not problematic > > > because of the rules for sending subsequent FWD-TSN in receipt > > > of SACK. It is only in this case where there is no further data > > > to send. > > > > > > As this only appears to be a problem in this one situation (not > > > subsequent DATA to send and no SACKs forthcoming), it might be > > > possible to handle this with a SHUTDOWN rule such as follows: > > > > > > Whenever the PR-SCTP sender enters the SHUTDOWN-PENDING state, > > > and there are only TSNs marked dropped for retransmission (for > > > which FWD-TSNs have been sent) a SHUTDOWN chunk is sent and the > > > sender enters the SHUTDOWN-SENT state. (The same for > > > SHUTDOWN-RECEIVED and SHUTDOWN-ACK-SENT states.) > > > > > > Whenever the PR-SCTP receiver receives a SHUTDOWN or > > > SHUTDOWN-ACK and there are gaps in its received TSN sequence > > > (messages awaiting reordering before delivery to the user), it > > > will treat the SHUTDOWN or SHUTDOWN-ACK though it were a forward > > > TSN for all missing data chunks. > > > > > > The trick here is to not delay the SHUTDOWN (or SHUTDOWN-ACK) > > > chunk being sent waiting for acknowledgement of dropped TSNs > > > but to send it anyways with the knowledge that the receiver can > > > imply any missing TSNs as having been dropped. > > > > > > I think this would better meet the intent of PR-SCTP (and in > > > particular timed-reliability) as it does not rely on a timer to > > > arrive at the implication of a missed FWD-TSN. The receipt of a > > > SHUTDOWN or SHUTDOWN-ACK can be treated as an implied FWD-TSN > > > for all outstanding data. > > > > > > Under the base protocol, what happens if a sender sends a > > > SHUTDOWN chunk *before* all its sent data is acknowledged? I > > > think an implementation could either complete the shutdown and > > > discard data awaiting reordering, or ABORT the association. For > > > PR-SCTP, receiving SHUTDOWN early could be construed as cause to > > > mark as dropped all outstanding data, and move the cummulative > > > ack point to the "highest" received TSN and complete the > > > SHUTDOWN procedure. > > > > > > Does that make sense? > > > > > > So effectively the rules would be that a SHUTDOWN or > > > SHUTDOWN-ACK should not be delayed in the SHUTDOWN-PENDING or > > > SHUTDOWN-RECEIVED states solely on the basis of unacknowledged > > > but "dropped" TSNs, and that a received SHUTDOWN or SHUTDOWN-ACK > > > chunk that is otherwise valid should be construed by the > > > receiver to have the same effect as a FWD-TSN dropping all > > > outstanding TSNs. > > > > > > Is that simpler than a timer? > > > > > > --brian > > > > > > > > > Whenever the receiver receives > > > > > > > > > On Mon, 05 May 2003, Randall Stewart (cisco) wrote: > > > > > >> Ronnie: > > >> > > >> Nope, I don't think you are missing anything. I have > been testing the > > >> internal Cisco-IOS implementation of PR-SCTP against the > KAME stack > > >> and have reached the same conclusion. I think we need to > require that > > >> the > > >> receiver of a FWD-TSN send a SACK in reponse to this. Otherwise > > >> you have this deadlock scenario.... I have made the KAME stack > > >> send the SACK.. but this then begs another question... > > >> > > >> If the SACK in the return path was lost (I am testing at > times with > > >> error rates set to 20%... so that happens a lot).. what do we do? > > >> > > >> It almost sounds like we need not only to require a FWD-TSN get > > >> a SACK in response.. but that the sender of the FWD-TSN, if no > > >> other data is being sent, start a timer to retransmit the FWD-TSN > > >> if no SACK is received.. not sure if I worded that clear > but I think > > >> it will be needed... > > >> > > >> Co-authors.. what do you-all think? > > >> > > >> R > > >> > > >> > > >> Sellar, Ronnie wrote: > > >> > > >>> Hi, > > >>> > > >>> We have just started looking at PR-SCTP with a view to having a > > >>> prototype > > >>> implementation ready for the next Interop in Delaware > and have come > > >>> up with > > >>> a question regarding the FORWARD-TSN chunk and how it > could affect > > >>> association termination. > > >>> > > >>> Consider the following example. Endpoint A has an > association with > > >>> endpoint > > >>> B in which all the data it sends is ordered and marked as > > >>> 'unreliable' for > > >>> whatever reason. Endpoint A has now sent all the data > it wants to > > >>> send to B > > >>> but can't yet close the association because B has not yet > > >>> acknowledged one > > >>> of the TSNs. Lets say that it has transmitted TSNs > 1-100 but has > > >>> not yet > > >>> received an acknowledgement of TSN 97 since B has not > yet received > > >>> that TSN. > > >>> > > >>> In this situation A cannot yet send the SHUTDOWN since > not all data > > >>> is acked > > >>> and B has three chunks it cannot deliver to it's user > (98, 99 and > > >>> 100) since > > >>> it has not received 97. When A receives the last SACK > it decides > > >>> that it no > > >>> longer wants to retransmit chunk 97 and so issues a FORWARD-TSN > > >>> chunk to > > >>> move the cumulative ack TSN on to 100. How does A know that B > > >>> received the > > >>> FORWARD-TSN chunk ? There is no more data to send so B > will not be > > >>> sending > > >>> any more SACKs. If B sends no more SACKs A's > cumulative ack TSN > > >>> will not > > >>> advance and so he will not be able to send the SHUTDOWN chunk. > > >>> > > >>> In B's case when he receives the FORWARD-TSN he will be happy, > > >>> deliver > > >>> 98-100 to the user and move his cumulative TSN forward. > But he is > > >>> not > > >>> required to send a SACK to tell A he has done so. Are > we now in a > > >>> stalemate > > >>> situation ? > > >>> > > >>> Also consider the case where B never receives the > FORWARD-TSN. He > > >>> is now > > >>> stuck with 98-100 in his buffers which he cannot > deliver since he > > >>> doesn't > > >>> know that 97 is not coming. Have we reached a similar > stalemate ? > > >>> > > >>> Perhaps I'm missing something, but I do think there > seems to be a > > >>> problem if > > >>> a FORWARD-TSN chunk is the last chunk to be transmitted on an > > >>> association. > > >>> Please feel free to correct me if I'm wrong. > > >>> > > >>> Cheers > > >>> > > >>> Ronnie > > >>> > > >>> --- > > >>> Ronnie Sellar Artesyn Communications Products > > >>> Tel: +44 131 475 7015 Suite 4, 2 Anderson Place > > >>> Fax: +44 131 475 7001 Edinburgh EH6 5NP > > >>> mailto:ronnie@artesyncp.com http://www.artesyncp.com > > >>> > > >>> > > >>> > > >> > > >> > > >> -- > > >> Randall R. Stewart > > >> ITD > > >> Cisco Systems Inc. > > >> rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) > > >> > > > > > > -- > > > Brian F. G. Bidulock ¦ The reasonable man adapts > himself to the ¦ > > > bidulock@openss7.org ¦ world; the unreasonable one > persists in ¦ > > > http://www.openss7.org/ ¦ trying to adapt the world to > himself. ¦ > > > ¦ Therefore all progress > depends on the ¦ > > > ¦ unreasonable man. -- George > Bernard Shaw ¦ > > > > > -- > Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ > bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ > http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ > ¦ Therefore all progress depends on the ¦ > ¦ unreasonable man. -- George Bernard Shaw ¦ > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed May 7 08:22:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27395 for ; Wed, 7 May 2003 08:22:29 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h47CVR710506 for tsvwg-archive@odin.ietf.org; Wed, 7 May 2003 08:31:27 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47CRV810272; Wed, 7 May 2003 08:27:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47CQc810222 for ; Wed, 7 May 2003 08:26:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27189 for ; Wed, 7 May 2003 08:17:10 -0400 (EDT) From: Ivan.Arias-Rodriguez@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DNtD-0000XU-00 for tsvwg@ietf.org; Wed, 07 May 2003 08:19:15 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19DNtB-0000XE-00 for tsvwg@ietf.org; Wed, 07 May 2003 08:19:14 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h47CK4713047 for ; Wed, 7 May 2003 15:20:04 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 7 May 2003 15:20:04 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 7 May 2003 15:20:03 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 7 May 2003 15:20:03 +0300 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 7 May 2003 15:20:02 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 7 May 2003 15:20:01 +0300 Message-ID: Thread-Topic: PR-SCTP question. Thread-Index: AcMUDgYMvjl1KDbmSiOXE6Cf7rLJ5gAgKn5g To: , Cc: , , , , , , , X-OriginalArrivalTime: 07 May 2003 12:20:02.0563 (UTC) FILETIME=[FC352D30:01C31492] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h47CQe810224 Subject: [Tsvwg] RE: PR-SCTP question. Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi all! I cannot see that new document because it seems there is a problem with the server (HTTP 500 - Internal server error) However, I support the idea of Michael... If you treat the FWD-TSN as actually sending the TSNs, you just share the T3 timer and you don't add any extra complication... This way you continue keeping the "logic" of the protocol, not adding special rules for PR-SCTP that might not be very straightforward to guess... So I think that whenever you mark a TSN as dropped (probably when T3 timer expires or even due to FR), you send the FWD-TSN chunk (if possible to a secondary address as happens with the DATA chunks) and (re)start the T3 timer (of that address to which you sent the chunk). I'm thinking that if all your packets have a lifespan of let's say 200 ms, you could even modify the value of RTO.Min to that value so you quickly drop the stale TSNs... Everything is the same as when sending DATA chunks, except for the congestion parameters that don't change upon receipt of a SACK originated by a FWD-TSN. If the T3 timer expires again on already dropped TSNs (and so you have already sent the FWD-TSN) you should also update the RTO and cut down the cwnd and so on as usual, since this really means that the chunk was effectively lost (you didn't receive the SACK). This way, the stated problem would disappear, and in my opinion, everything would look more homogeneous and easier... What do you think? Thanks! BR Iván Arias Rodríguez > -----Original Message----- > From: ext Randall Stewart (cisco) [mailto:rrs@cisco.com] > Sent: Tuesday, 06 May, 2003 23:12 > To: Qiaobing Xie > Cc: Sellar@az33exr01.mot.com; Ronnie; 'bidulock@openss7.org'; Michael > Tüxen; tsvwg@ietf.org; Sctp-Impl (E-mail); Phillip T. Conrad; > Michael A. > Ramalho > Subject: Re: PR-SCTP question. > > > Dear all: > > I have made what I think are the appropriate changes and I would > like you all to take a look. I have put up on > > http://www.sctp.org > > under the RFC page tab > > A web link that will take you to a very nice diff of the > 02/03 version. > > Please take a few moments to look at the diff's and suggest > any changes > > I would like to get this sumbitted by Friday. > > R > > > > > Qiaobing Xie wrote: > > >"Randall Stewart (cisco)" wrote: > > > > > >>Ronnie/Brian: > >> > >>I think this is the correct solution... > >> > >>It then requires: > >> > >>1) A note on the receiver side .. aka handle like data .. > you must start the > >> sack timer etc > >> > >>and > >> > >>2) A note on the sender side.. aka you don't stop the > t3-timer if there > >> is no outstanding data.. and when the t3-timer goes > off you should > >> send a fwd-tsn as well as any retransmmitted data.. > >> > >>I will see if I can't cut and past from this email and do a bit > >>of massaging to get the proper notes in the document.. > >> > >>I too view the FWD-TSN as nothing but a compressed "heres the data > >>I am skipping and not sending"... > >> > >> > > > >This is indeed a good way to look at it. And I think the solution > >summarized by Brian and Randy is the right approach. > > > >-Qiaobing > > > > > > > > > >>R > >> > >> > >> > >> > > > > > > > > > -- > Randall R. Stewart > ITD > Cisco Systems Inc. > rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) > > > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed May 7 12:47:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07931 for ; Wed, 7 May 2003 12:47:59 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h47Gv1W01358 for tsvwg-archive@odin.ietf.org; Wed, 7 May 2003 12:57:01 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47GsL801255; Wed, 7 May 2003 12:54:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47GqE801164 for ; Wed, 7 May 2003 12:52:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07826 for ; Wed, 7 May 2003 12:42:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DS29-0002pt-00 for tsvwg@ietf.org; Wed, 07 May 2003 12:44:45 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by ietf-mx with esmtp (Exim 4.12) id 19DS28-0002pf-00 for tsvwg@ietf.org; Wed, 07 May 2003 12:44:44 -0400 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h47GiXs2011205; Wed, 7 May 2003 09:44:33 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AGX86122; Wed, 7 May 2003 09:44:29 -0700 (PDT) Message-ID: <3EB937EB.7080704@cisco.com> Date: Wed, 07 May 2003 11:44:27 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3) Gecko/20030502 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Sellar, Ronnie" CC: Qiaobing Xie , "'bidulock@openss7.org'" , =?ISO-8859-1?Q?Michael_T=FCxen?= , tsvwg@ietf.org, "Sctp-Impl (E-mail)" , "Phillip T. Conrad" , "Michael A. Ramalho" References: <797470E884C6D611B7A500B0D0AA56D0442704@batistuta.spider.com> In-Reply-To: <797470E884C6D611B7A500B0D0AA56D0442704@batistuta.spider.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by sj-core-2.cisco.com id h47GiXs2011205 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h47GqE801165 Subject: [Tsvwg] Re: PR-SCTP question. Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Sellar, Ronnie wrote: >Randall: > >One further question. Does the advanced.peer.ack.point get moved backwards >if acked data that it relies on is reneged ? This doesn't seem to be >mentioned in the draft. > Hmm.. I am lost on this one.. I do ---1---------> ---2---------> ---3----------> and now I decide I am placing 1 and 3 as no longer abandoned... Now I send fwd-tsn only for 1 (I can't get by 2..since it is reliable.. or not yet abandonded). I can't mention 3... until it is at the top.. I guess I am unclear on your quesitons.. can you illustrate with soemthing like the above>? > >One or two typos: in rule A2) there's and 'rxt' that should be an 'rtx', > good catch.. >and >in section 3.4 there is a "drop" which perhaps should be an "abandon". > good catch.. I fixed both of these in the XML. Thanks R > >Thanks > >Ronnie > >PS I'm not in the office again till Monday but Gavin Shearer will be >monitoring the newsgroup. > >--- >Ronnie Sellar Artesyn Communications Products >Tel: +44 131 475 7015 Suite 4, 2 Anderson Place >Fax: +44 131 475 7001 Edinburgh EH6 5NP >mailto:ronnie@artesyncp.com http://www.artesyncp.com > > > >>-----Original Message----- >>From: Randall Stewart (cisco) [mailto:rrs@cisco.com] >>Sent: 06 May 2003 21:12 >>To: Qiaobing Xie >>Cc: Sellar@az33exr01.mot.com; Ronnie; 'bidulock@openss7.org'; Michael >>Tüxen; tsvwg@ietf.org; Sctp-Impl (E-mail); Phillip T. Conrad; >>Michael A. >>Ramalho >>Subject: Re: PR-SCTP question. >> >> >>Dear all: >> >>I have made what I think are the appropriate changes and I would >>like you all to take a look. I have put up on >> >>http://www.sctp.org >> >>under the RFC page tab >> >>A web link that will take you to a very nice diff of the >>02/03 version. >> >>Please take a few moments to look at the diff's and suggest >>any changes >> >>I would like to get this sumbitted by Friday. >> >>R >> >> >> >> >>Qiaobing Xie wrote: >> >> >> >>>"Randall Stewart (cisco)" wrote: >>> >>> >>> >>> >>>>Ronnie/Brian: >>>> >>>>I think this is the correct solution... >>>> >>>>It then requires: >>>> >>>>1) A note on the receiver side .. aka handle like data .. >>>> >>>> >>you must start the >> >> >>>> sack timer etc >>>> >>>>and >>>> >>>>2) A note on the sender side.. aka you don't stop the >>>> >>>> >>t3-timer if there >> >> >>>> is no outstanding data.. and when the t3-timer goes >>>> >>>> >>off you should >> >> >>>> send a fwd-tsn as well as any retransmmitted data.. >>>> >>>>I will see if I can't cut and past from this email and do a bit >>>>of massaging to get the proper notes in the document.. >>>> >>>>I too view the FWD-TSN as nothing but a compressed "heres the data >>>>I am skipping and not sending"... >>>> >>>> >>>> >>>> >>>This is indeed a good way to look at it. And I think the solution >>>summarized by Brian and Randy is the right approach. >>> >>>-Qiaobing >>> >>> >>> >>> >>> >>> >>>>R >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>-- >>Randall R. Stewart >>ITD >>Cisco Systems Inc. >>rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) >> >> >> > > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed May 7 15:54:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15250 for ; Wed, 7 May 2003 15:54:35 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h47K3hN17280 for tsvwg-archive@odin.ietf.org; Wed, 7 May 2003 16:03:43 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47K1o817179; Wed, 7 May 2003 16:01:50 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47FjT827656 for ; Wed, 7 May 2003 11:45:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06001 for ; Wed, 7 May 2003 11:35:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DQzZ-0002QV-00 for tsvwg@ietf.org; Wed, 07 May 2003 11:38:01 -0400 Received: from [194.217.109.12] (helo=bifrost.spider.com) by ietf-mx with smtp (Exim 4.12) id 19DQzY-0002QS-00 for tsvwg@ietf.org; Wed, 07 May 2003 11:38:00 -0400 Received: from no.name.available by bifrost.spider.com via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; 7 May 2003 15:38:48 UT Received: from heimdall-dmz.spider.com (batistuta.spider.com [212.240.99.13]) by caly80.spider.com (Postfix) with SMTP id AED0E6F81; Wed, 7 May 2003 16:34:35 +0100 (BST) Received: from batistuta.spider.com by heimdall-dmz.spider.com via smtpd (for [172.16.254.22]) with SMTP; 7 May 2003 15:38:46 UT Received: by batistuta.spider.com with Internet Mail Service (5.5.2653.19) id ; Wed, 7 May 2003 16:35:56 +0100 Message-ID: <797470E884C6D611B7A500B0D0AA56D0442704@batistuta.spider.com> From: "Sellar, Ronnie" To: "'Randall Stewart (cisco)'" , Qiaobing Xie Cc: "'bidulock@openss7.org'" , =?iso-8859-1?Q?Michael_T=FCxen?= , tsvwg@ietf.org, "Sctp-Impl (E-mail)" , "Phillip T. Conrad" , "Michael A. Ramalho" Date: Wed, 7 May 2003 16:35:48 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h47FjT827657 Subject: [Tsvwg] RE: PR-SCTP question. Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Randall: One further question. Does the advanced.peer.ack.point get moved backwards if acked data that it relies on is reneged ? This doesn't seem to be mentioned in the draft. One or two typos: in rule A2) there's and 'rxt' that should be an 'rtx', and in section 3.4 there is a "drop" which perhaps should be an "abandon". Thanks Ronnie PS I'm not in the office again till Monday but Gavin Shearer will be monitoring the newsgroup. --- Ronnie Sellar Artesyn Communications Products Tel: +44 131 475 7015 Suite 4, 2 Anderson Place Fax: +44 131 475 7001 Edinburgh EH6 5NP mailto:ronnie@artesyncp.com http://www.artesyncp.com > -----Original Message----- > From: Randall Stewart (cisco) [mailto:rrs@cisco.com] > Sent: 06 May 2003 21:12 > To: Qiaobing Xie > Cc: Sellar@az33exr01.mot.com; Ronnie; 'bidulock@openss7.org'; Michael > Tüxen; tsvwg@ietf.org; Sctp-Impl (E-mail); Phillip T. Conrad; > Michael A. > Ramalho > Subject: Re: PR-SCTP question. > > > Dear all: > > I have made what I think are the appropriate changes and I would > like you all to take a look. I have put up on > > http://www.sctp.org > > under the RFC page tab > > A web link that will take you to a very nice diff of the > 02/03 version. > > Please take a few moments to look at the diff's and suggest > any changes > > I would like to get this sumbitted by Friday. > > R > > > > > Qiaobing Xie wrote: > > >"Randall Stewart (cisco)" wrote: > > > > > >>Ronnie/Brian: > >> > >>I think this is the correct solution... > >> > >>It then requires: > >> > >>1) A note on the receiver side .. aka handle like data .. > you must start the > >> sack timer etc > >> > >>and > >> > >>2) A note on the sender side.. aka you don't stop the > t3-timer if there > >> is no outstanding data.. and when the t3-timer goes > off you should > >> send a fwd-tsn as well as any retransmmitted data.. > >> > >>I will see if I can't cut and past from this email and do a bit > >>of massaging to get the proper notes in the document.. > >> > >>I too view the FWD-TSN as nothing but a compressed "heres the data > >>I am skipping and not sending"... > >> > >> > > > >This is indeed a good way to look at it. And I think the solution > >summarized by Brian and Randy is the right approach. > > > >-Qiaobing > > > > > > > > > >>R > >> > >> > >> > >> > > > > > > > > > -- > Randall R. Stewart > ITD > Cisco Systems Inc. > rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) > > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed May 7 15:56:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15291 for ; Wed, 7 May 2003 15:56:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h47K5CF17338 for tsvwg-archive@odin.ietf.org; Wed, 7 May 2003 16:05:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47K21817197; Wed, 7 May 2003 16:02:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47FsS828149 for ; Wed, 7 May 2003 11:54:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06245 for ; Wed, 7 May 2003 11:44:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DR8G-0002Tx-00 for tsvwg@ietf.org; Wed, 07 May 2003 11:47:00 -0400 Received: from stewart.chicago.il.us ([66.93.186.36]) by ietf-mx with esmtp (Exim 4.12) id 19DR8F-0002Th-00 for tsvwg@ietf.org; Wed, 07 May 2003 11:46:59 -0400 Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8p1/8.12.8) with ESMTP id h47Fd3qh005358; Wed, 7 May 2003 10:39:07 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3EB92897.8070407@stewart.chicago.il.us> Date: Wed, 07 May 2003 10:39:03 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3) Gecko/20030502 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ivan.Arias-Rodriguez@nokia.com CC: rrs@cisco.com, Qiaobing.Xie@motorola.com, Sellar@az33exr01.mot.com, ronnie@artesyncp.com, bidulock@openss7.org, tuexen@fh-muenster.de, tsvwg@ietf.org, sctp-impl@external.cisco.com, conrad@acm.org, mramalho@cisco.com Subject: Re: [Tsvwg] RE: PR-SCTP question. References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by stewart.chicago.il.us id h47Fd3qh005358 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h47FsS828150 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hmm.. I will have to go have a look at what is going on in my server.. I will send you (and anywone esle that requests it) a copy of the html Thanks R Ivan.Arias-Rodriguez@nokia.com wrote: > Hi all! > > I cannot see that new document because it seems there is a problem with the server (HTTP 500 - Internal server error) > > However, I support the idea of Michael... If you treat the FWD-TSN as actually sending the TSNs, you just share the T3 timer and you don't add any extra complication... > > This way you continue keeping the "logic" of the protocol, not adding special rules for PR-SCTP that might not be very straightforward to guess... > > So I think that whenever you mark a TSN as dropped (probably when T3 timer expires or even due to FR), you send the FWD-TSN chunk (if possible to a secondary address as happens with the DATA chunks) and (re)start the T3 timer (of that address to which you sent the chunk). I'm thinking that if all your packets have a lifespan of let's say 200 ms, you could even modify the value of RTO.Min to that value so you quickly drop the stale TSNs... > > Everything is the same as when sending DATA chunks, except for the congestion parameters that don't change upon receipt of a SACK originated by a FWD-TSN. If the T3 timer expires again on already dropped TSNs (and so you have already sent the FWD-TSN) you should also update the RTO and cut down the cwnd and so on as usual, since this really means that the chunk was effectively lost (you didn't receive the SACK). > > This way, the stated problem would disappear, and in my opinion, everything would look more homogeneous and easier... What do you think? > > Thanks! > > BR Iván Arias Rodríguez > > >>-----Original Message----- >>From: ext Randall Stewart (cisco) [mailto:rrs@cisco.com] >>Sent: Tuesday, 06 May, 2003 23:12 >>To: Qiaobing Xie >>Cc: Sellar@az33exr01.mot.com; Ronnie; 'bidulock@openss7.org'; Michael >>Tüxen; tsvwg@ietf.org; Sctp-Impl (E-mail); Phillip T. Conrad; >>Michael A. >>Ramalho >>Subject: Re: PR-SCTP question. >> >> >>Dear all: >> >>I have made what I think are the appropriate changes and I would >>like you all to take a look. I have put up on >> >>http://www.sctp.org >> >>under the RFC page tab >> >>A web link that will take you to a very nice diff of the >>02/03 version. >> >>Please take a few moments to look at the diff's and suggest >>any changes >> >>I would like to get this sumbitted by Friday. >> >>R >> >> >> >> >>Qiaobing Xie wrote: >> >> >>>"Randall Stewart (cisco)" wrote: >>> >>> >>> >>>>Ronnie/Brian: >>>> >>>>I think this is the correct solution... >>>> >>>>It then requires: >>>> >>>>1) A note on the receiver side .. aka handle like data .. >> >>you must start the >> >>>> sack timer etc >>>> >>>>and >>>> >>>>2) A note on the sender side.. aka you don't stop the >> >>t3-timer if there >> >>>> is no outstanding data.. and when the t3-timer goes >> >>off you should >> >>>> send a fwd-tsn as well as any retransmmitted data.. >>>> >>>>I will see if I can't cut and past from this email and do a bit >>>>of massaging to get the proper notes in the document.. >>>> >>>>I too view the FWD-TSN as nothing but a compressed "heres the data >>>>I am skipping and not sending"... >>>> >>>> >>> >>>This is indeed a good way to look at it. And I think the solution >>>summarized by Brian and Randy is the right approach. >>> >>>-Qiaobing >>> >>> >>> >>> >>> >>>>R >>>> >>>> >>>> >>>> >>> >>> >>> >> >> >>-- >>Randall R. Stewart >>ITD >>Cisco Systems Inc. >>rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) >> >> >> > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > > -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu May 8 06:36:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19225 for ; Thu, 8 May 2003 06:36:42 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h48Ak7v32643 for tsvwg-archive@odin.ietf.org; Thu, 8 May 2003 06:46:07 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h48Aiw832583; Thu, 8 May 2003 06:44:58 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h48AhU832518 for ; Thu, 8 May 2003 06:43:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19174 for ; Thu, 8 May 2003 06:33:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DikU-00027Z-00 for tsvwg@ietf.org; Thu, 08 May 2003 06:35:38 -0400 Received: from gw.openss7.com ([142.179.199.224] ident=[lPIh07QQBHr7vaIFdUl4h0FVlsIWLlVy]) by ietf-mx with esmtp (Exim 4.12) id 19DikT-00027W-00 for tsvwg@ietf.org; Thu, 08 May 2003 06:35:37 -0400 Received: from ns.pigworks.openss7.net (IDENT:Gy5IfOFv5NBDIUs2lTj7ry19BRIyNRfx@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h48AaVl31684; Thu, 8 May 2003 04:36:31 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h48AaUU26982; Thu, 8 May 2003 04:36:30 -0600 Date: Thu, 8 May 2003 04:36:30 -0600 From: "Brian F. G. Bidulock" To: Gavin Shearer Cc: sctp-impl@external.cisco.com, tsvwg@ietf.org Message-ID: <20030508043630.A26708@openss7.org> Reply-To: bidulock@openss7.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from gavin@artesyncp.com on Thu, May 08, 2003 at 10:15:24AM +0100 Organization: http://www.openss7.org/ Dsn-Notification-To: X-MIME-Autoconverted: from 8bit to quoted-printable by gw.openss7.com id h48AaVl31684 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h48AhU832519 Subject: [Tsvwg] Re: PR-SCTP question (T3 timers) Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Gavin, That's what I did too. It makes sense. However, if a new FWD TSN is sent (because new TSNs are dropped pushing the advanced ack point), I also cancel the fact that a previous FWD TSN was outstanding against the destination to which the previous FWD TSN was sent. We might now consider that FWD TSNs need not be delayed for bundling by 200 to 500 ms. In fact if the TSNs are marked dropped and an FWD TSN is to be transmitted on t3-rtx timeout, we might as well only wait for the normal t3-rtx timeout (even if it is greater than 500ms) before sending the FWD TSN. This would have the effect of bundling the FWD TSN with unexpired retransmitted TSNs, or at worst only retransmitting the FWD TSN once an RTO and would back off sending of FWD TSNs during periods of congestion rather than sending every 200-500 ms without data (no back off). Is the 200-500ms still in the new draft? --brian On Thu, 08 May 2003, Gavin Shearer wrote: > I have some queries/suggestions about handling the T3 timer(s) with > PR-SCTP. > > As each destination address has a T3 timer, there can be multiple T3 > timers running if you are sending to different destination addresses of > the peer. Therefore, as the draft/updates are worded, it is unclear > which T3 timer is stopped and the expiry of which causes sending again > of a F-TSN. (If it was all T3 timers which caused sending again, you > may send the F-TSN more than once even if you do not need to.) > > Therefore, carrying on with the theme of treating the packet as summary > of data, I would think it makes sense for the F-TSN to be treated like > the bundling of the abandoned chunks being retransmitted to a > particular address. Therefore the T3 timer handling would be handled > in the same way. > > This means you would start the T3 timer for the destination address of > the F-TSN if not already running. So, when a T3 timer expires you > would only send the F-TSN again if the T3 timer expired for the address > sent the F-TSN. (This could be implemented by checking that this is the > address at least one abandoned chunk was last "sent" to, if you note > the address a chunk is sent to in the same way as (re)transmitting > a chunk). > > Of course, if you re-send the F-TSN to an alternative address, then the > F-TSN will be noted as outstanding on that address, in the same manner > as you would treat retransmitting DATA to an alternative address. > > I think this would change the wording of: > > A2) You would not say that the T3-rtx timer is not stopped - i.e. > remove that line. > > [I think this would be the case, as when retransmitting you > do not stop the T3 timer of an earlier address when > retransmitting on an alternative address, see RFC2960 6.3.3 F1).] > > For the new paragraph covering sending due to the T3 expiring > you would put in an additional condition of the T3-rtx timer > expiring for the destination address sent the F-TSN. > > > C3) You would say that sending the F-TSN is treated like > retransmission of the abandoned chunks when handling the T3-timers. > You may want to emphasize that the T3 timer for the > destination address should be started if not already running. > > Gavin > --- > Gavin Shearer, Suite 4, gavin@artesyncp.com > Project Leader, 2 Anderson Place, +44 131 475 7017 > Artesyn Communication Products Edinburgh, EH6 5NP -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu May 8 08:36:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21050 for ; Thu, 8 May 2003 08:36:21 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h48CjmC08199 for tsvwg-archive@odin.ietf.org; Thu, 8 May 2003 08:45:48 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h48CiG808132; Thu, 8 May 2003 08:44:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h48ChC808061 for ; Thu, 8 May 2003 08:43:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20981 for ; Thu, 8 May 2003 08:33:15 -0400 (EDT) From: Ivan.Arias-Rodriguez@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DkcI-0002aP-00 for tsvwg@ietf.org; Thu, 08 May 2003 08:35:18 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19DkcH-0002aM-00 for tsvwg@ietf.org; Thu, 08 May 2003 08:35:17 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h48CaB727015 for ; Thu, 8 May 2003 15:36:11 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 8 May 2003 15:36:10 +0300 Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 8 May 2003 15:36:09 +0300 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 8 May 2003 15:36:09 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 8 May 2003 15:36:08 +0300 Message-ID: Thread-Topic: Comments about prsctp-03.txt (and latest changes) Thread-Index: AcMVXmagHCWwcqdqRauhTUBc5MtyaQ== To: X-OriginalArrivalTime: 08 May 2003 12:36:09.0636 (UTC) FILETIME=[670A8E40:01C3155E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h48ChC808062 Subject: [Tsvwg] Comments about prsctp-03.txt (and latest changes) Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi all! I have just read the version 03 of the document and I have the next comments and several small typos: - First of all: Why the diff document at www.sctp.org is done taking as the basis the version 02? :-/ just curious... - Section 1.1, 2): I suppose that "Data chunks" should be "DATA chunks"... - Section 1.2, first paragraph, last words: Instead of "... send the message to receiver." might be "... send the message to the receiver." - Section 3.2, definitions of Stream-N and Stream Sequence-N: It speaks about "skipped streams" here... I think I understand what it means but it is ambiguous for me... Is it something like "streams to which were directed one or more of the abandoned DATA chunks reported in this FORWARD TSN chunk"? Uff, too long... maybe "skipped" is still better... :-) And what about the meaning of Stream Sequence-N? What I understand is that it is the previous to the next SSN that could be delivered to the upper user, i.e., all the SSNs earlier to this number can already be delivered even though there are earlier SSNs that have not yet arrived... Am I right? By the way, the graphic at the beginning of the page shows "*Steam* Sequence-1"... - Section 3.3.3, beginning of 10th page: Forgive me for this comment but, what about gracefully closing the association? Later in this section, in 2) there is a typo: "reliablilty". - Section 3.4, A2): It doesn't say here anything about updating the Advanced.Peer.Ack.Point, should it? - Section 3.4, C4): It says "drop's" here, I guess it could be... "abandonings"? There are another two "drop"s in section 4.1 TR3) and TR4). - Section 3.6, first paragraph: Should the "end point" written here be "endpoint" instead? - Section 3.6, page 14: There is here a rule to treat a FORWARD TSN as out-of-date and discard it, but I'm not convinced it is right... Imagine the sender has sent TSNs 101, 102 and 103. TSN 103 arrived normally, 102 was lost in the network, and 101 was delayed enough time to make the T3 timer expire and send the FORWARD TSN chunk before the SACK reached the data sender. If the sender has not received yet the SACK for TSN 101, and in case 102 is abandoned at this point (but 101 is not), the "New Cumulative TSN" of the FORWARD TSN chunk will be set to 100, however, the Cumulative TSN at the receiver is already 101, and the information carried in the FORWARD TSN chunk would help the data receiver advance its Cumulative TSN to at least 103... Hmm... I don't think this rule is valid... :-/ - Section 4.3, beginning of page 18: Typo. "...) than those additional..." should be "...) then those additional..." - Section 6: I guess there is a period missing at the end, between "security" and "further"... I think this is enough this time :-) Thanks! BR Iván Arias Rodríguez _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu May 8 10:23:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24797 for ; Thu, 8 May 2003 10:23:42 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h48EXCQ16243 for tsvwg-archive@odin.ietf.org; Thu, 8 May 2003 10:33:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h48EVW816131; Thu, 8 May 2003 10:31:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h48EUT816031 for ; Thu, 8 May 2003 10:30:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24718 for ; Thu, 8 May 2003 10:20:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DmI4-000383-00 for tsvwg@ietf.org; Thu, 08 May 2003 10:22:32 -0400 Received: from stewart.chicago.il.us ([66.93.186.36]) by ietf-mx with esmtp (Exim 4.12) id 19DmI3-00037g-00 for tsvwg@ietf.org; Thu, 08 May 2003 10:22:31 -0400 Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8p1/8.12.8) with ESMTP id h48EMnrf007325; Thu, 8 May 2003 09:22:54 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3EBA6837.1040502@stewart.chicago.il.us> Date: Thu, 08 May 2003 09:22:47 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3) Gecko/20030502 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ivan.Arias-Rodriguez@nokia.com CC: tsvwg@ietf.org Subject: Re: [Tsvwg] Comments about prsctp-03.txt (and latest changes) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by stewart.chicago.il.us id h48EMnrf007325 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h48EUT816032 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Ivan.Arias-Rodriguez@nokia.com wrote: > Hi all! > > I have just read the version 03 of the document and I have the next > comments and several small typos: > > - First of all: Why the diff document at www.sctp.org is done taking > as the basis the version 02? :-/ just curious... Opps.. because I fat fingered the diff.. I will redo it :> > > - Section 1.1, 2): I suppose that "Data chunks" should be "DATA > chunks"... > ok > - Section 1.2, first paragraph, last words: Instead of "... send the > message to receiver." might be "... send the message to the > receiver." > good cach. > - Section 3.2, definitions of Stream-N and Stream Sequence-N: It > speaks about "skipped streams" here... I think I understand what it > means but it is ambiguous for me... Is it something like "streams to > which were directed one or more of the abandoned DATA chunks reported > in this FORWARD TSN chunk"? Uff, too long... maybe "skipped" is still > better... :-) You have it right.. but it is a bit hard to put down.. without being very long :-0.. Of course so far these suggestions you have made have nothing to do with the new changes.. but thats ok :> Don't know how to define 3.2 better.. It does specify: " Stream-N: 16 bit u_int This field holds a stream number that was skipped by this FWD-TSN. Stream Sequence-N: 16 bit u_int This field holds the sequence number associated with the stream that was skipped. The receiver of the FWD-TSN's can use the Stream-N and Stream Sequence-N fields to enable delivery of any stranded TSN's that remain on the stream re-ordering queues. " Which if you read all together I think is clear... > > And what about the meaning of Stream Sequence-N? What I understand is > that it is the previous to the next SSN that could be delivered to > the upper user, i.e., all the SSNs earlier to this number can already > be delivered even though there are earlier SSNs that have not yet > arrived... Am I right? > Yep... its the highest stream sequence in this stream number that can be skiped... so if you do abandon (TSN=888 STR=1 SEQ=5 and abandon (TSN=889 STR=1 SEQ=6) Then your FWD-TSN would have STREAM- 1 SEQUENCE-6 In its report. > By the way, the graphic at the beginning of the page shows "*Steam* > Sequence-1"... Yes.. and it is labeld Stream Sequence-N and so the graphic shows Stream Sequence-1 Is this not what one would expect... if we want to kill the word stream thats ok.. I just don't understand why you need to.. it is after all a "stream sequence" number... > > - Section 3.3.3, beginning of 10th page: Forgive me for this comment > but, what about gracefully closing the association? Later in this > section, in 2) there is a typo: "reliablilty". Got the reliablity...but if you are just starting the association I.e. have either sent the INIT or received it... there is NO association to gracefully close.. so one would abort it not close it.. Otherwise one would need to finish the 4-way handshake and THEN shut it down.. which makes no sense to me...am I missing something? > > - Section 3.4, A2): It doesn't say here anything about updating the > Advanced.Peer.Ack.Point, should Good point.. you should try to advance the ack point if possible as well as resend a new fwd-tsn. > > - Section 3.4, C4): It says "drop's" here, I guess it could be... > "abandonings"? There are another two "drop"s in section 4.1 TR3) and > TR4). > Ok, got them.. even though I think abandonings is a bit strange.. I can't think of any other way to word it :> > - Section 3.6, first paragraph: Should the "end point" written here > be "endpoint" instead? > Yep thats a typo. > - Section 3.6, page 14: There is here a rule to treat a FORWARD TSN > as out-of-date and discard it, but I'm not convinced it is right... > > Imagine the sender has sent TSNs 101, 102 and 103. TSN 103 arrived > normally, 102 was lost in the network, and 101 was delayed enough > time to make the T3 timer expire and send the FORWARD TSN chunk > before the SACK reached the data sender. So let me get this right CUM-ACK=100 I send ---TSN101--->Xdelayed ---TSN102--->Xlost ---TSN103--------------------------> <-------------SACK(100, got103-103)--- Now t3-rxt goes off on 101 so I ----FORWARD-TSN(101)--------> > > If the sender has not received yet the SACK for TSN 101, and in case > 102 is abandoned at this point (but 101 is not), Now wait... no I mis-understand your diagram.. you are not skipping 101, but 102... So at the point the T3-Timer goes off you have 101-- still good need resend 102-- mark to abandon 103-- Acked with gap-acks In this case your advanced peer ack point will still be at 100 (the same as the cum-ack) so you can NOT send a fwd-tsn.. Not until the SACK(101) comes back and then your adv-peer-ack-point will be advanced. Note rule C2) and also note rule C3).. so in the first case C2 prevents you from moving a-p-a since 101 is still outstanding and is not marked to skip.. and C3) blocks you from sending a FWD-TSN since the a-p-a is equal to your Cum-Ack. In the second case (after SACK(101) arrives) you then can, by C2) set a-p-a to 102 and thus send a fwd-tsn.. I think there is nothing wrong with discarding old FWD-TSN's .. you may want to handle them the same way you would duplcaite data though.. and send a SACK().. the "New Cumulative > TSN" of the FORWARD TSN chunk will be set to 100, and won't be sent (see above) however, the > Cumulative TSN at the receiver is already 101, and the information > carried in the FORWARD TSN chunk would help the data receiver advance > its Cumulative TSN to at least 103... > > Hmm... I don't think this rule is valid... :-/ Please restate your example... if I missed something... I think its ok.. > > - Section 4.3, beginning of page 18: Typo. "...) than those > additional..." should be "...) then those additional..." got it. > > - Section 6: I guess there is a period missing at the end, between > "security" and "further"... > > I think this is enough this time :-) I will put a new diff (against -03 up with your new changes in :>) R > > Thanks! > > BR Iván Arias Rodríguez > _______________________________________________ tsvwg mailing list > tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg > > -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu May 8 10:42:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25257 for ; Thu, 8 May 2003 10:42:54 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h48EqOR18057 for tsvwg-archive@odin.ietf.org; Thu, 8 May 2003 10:52:24 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h48EpD817978; Thu, 8 May 2003 10:51:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h48Eok817947 for ; Thu, 8 May 2003 10:50:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25221 for ; Thu, 8 May 2003 10:40:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Dmbh-0003CV-00 for tsvwg@ietf.org; Thu, 08 May 2003 10:42:49 -0400 Received: from stewart.chicago.il.us ([66.93.186.36]) by ietf-mx with esmtp (Exim 4.12) id 19Dmbg-0003CP-00 for tsvwg@ietf.org; Thu, 08 May 2003 10:42:49 -0400 Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8p1/8.12.8) with ESMTP id h48EhCrf007459; Thu, 8 May 2003 09:43:13 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3EBA6D00.7000104@stewart.chicago.il.us> Date: Thu, 08 May 2003 09:43:12 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3) Gecko/20030502 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ivan.Arias-Rodriguez@nokia.com CC: tsvwg@ietf.org Subject: Re: [Tsvwg] Comments about prsctp-03.txt (and latest changes) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ivan/All: I have re-compared the -03 to -04 version.. this time with the right documents.. plus Ivan's changes and all comments that have been made so far. Please have a look at http://www.sctp.org under the rfc tab.. Note if anyone has problems with the site please contact me and I will either get things working or send a copy of the comparison doc. Thanks R -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu May 8 10:46:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25429 for ; Thu, 8 May 2003 10:46:59 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h48EuUb18303 for tsvwg-archive@odin.ietf.org; Thu, 8 May 2003 10:56:30 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h48Et4818171; Thu, 8 May 2003 10:55:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h48Erl818098 for ; Thu, 8 May 2003 10:53:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25284 for ; Thu, 8 May 2003 10:43:46 -0400 (EDT) From: Ivan.Arias-Rodriguez@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Dmec-0003D7-00 for tsvwg@ietf.org; Thu, 08 May 2003 10:45:50 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19Dmea-0003D4-00 for tsvwg@ietf.org; Thu, 08 May 2003 10:45:49 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h48Ekg723362 for ; Thu, 8 May 2003 17:46:42 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 8 May 2003 17:46:42 +0300 Received: from esebe011.NOE.Nokia.com ([172.21.138.50]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 8 May 2003 17:46:42 +0300 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe011.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 8 May 2003 17:46:41 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Tsvwg] Comments about prsctp-03.txt (and latest changes) Date: Thu, 8 May 2003 17:46:41 +0300 Message-ID: Thread-Topic: [Tsvwg] Comments about prsctp-03.txt (and latest changes) Thread-Index: AcMVbWboSWCn0zUtS0CcQV7AXo8oawAAVizg To: Cc: X-OriginalArrivalTime: 08 May 2003 14:46:41.0889 (UTC) FILETIME=[A36D8510:01C31570] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h48Erl818099 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit ... snip... > > And what about the meaning of Stream Sequence-N? What I > understand is > > that it is the previous to the next SSN that could be delivered to > > the upper user, i.e., all the SSNs earlier to this number > can already > > be delivered even though there are earlier SSNs that have not yet > > arrived... Am I right? > > > > Yep... its the highest stream sequence in this stream number > that can be skiped... so if you do > > abandon (TSN=888 STR=1 SEQ=5 > and > abandon (TSN=889 STR=1 SEQ=6) > > Then your FWD-TSN would > have > > STREAM- 1 SEQUENCE-6 > > In its report. Ok, now is even clearer... > > By the way, the graphic at the beginning of the page shows "*Steam* > > Sequence-1"... > > Yes.. and it is labeld > > Stream Sequence-N > > and so the graphic shows > Stream Sequence-1 > > Is this not what one would expect... if we want to kill the word > stream thats ok.. I just don't understand why you need to.. it is > after all a "stream sequence" number... The point is that there is an "r" missing. It says "Steam" instead of "Stream"... I guess that steam was going out of your head trying to figure out what I was meaning... ;-) > > - Section 3.3.3, beginning of 10th page: Forgive me for this comment > > but, what about gracefully closing the association? Later in this > > section, in 2) there is a typo: "reliablilty". > > Got the reliablity...but if you are just starting the association > I.e. have either sent the INIT or received it... there is NO > association to gracefully close.. so one would abort it not > close it.. Yes, in that case. But it says that the "... initiation process have already ended..." But it is a little silly comment from mine anyway... :-0 BTW, shouldn't it say "... initiation process *has* already ended..."? > Otherwise one would need to finish the 4-way handshake and THEN > shut it down.. which makes no sense to me...am I missing something? Well... read above... > > - Section 3.4, A2): It doesn't say here anything about updating the > > Advanced.Peer.Ack.Point, should > > Good point.. you should try to advance the ack point if possible > as well as resend a new fwd-tsn. > > > > > > - Section 3.4, C4): It says "drop's" here, I guess it could be... > > "abandonings"? There are another two "drop"s in section 4.1 TR3) and > > TR4). > > > Ok, got them.. even though I think abandonings is a bit strange.. I Yep... Well, it is you whose mother tongue is English, so... :-) > can't think of any other way to word it :> > > > - Section 3.6, first paragraph: Should the "end point" written here > > be "endpoint" instead? > > > Yep thats a typo. > > > - Section 3.6, page 14: There is here a rule to treat a FORWARD TSN > > as out-of-date and discard it, but I'm not convinced it is right... > > > > Imagine the sender has sent TSNs 101, 102 and 103. TSN 103 arrived > > normally, 102 was lost in the network, and 101 was delayed enough > > time to make the T3 timer expire and send the FORWARD TSN chunk > > before the SACK reached the data sender. > So let me get this right > > CUM-ACK=100 > > I send > > ---TSN101--->Xdelayed > ---TSN102--->Xlost > ---TSN103--------------------------> > <-------------SACK(100, got103-103)--- > Now t3-rxt goes off on 101 so I > > ----FORWARD-TSN(101)--------> > > > > > If the sender has not received yet the SACK for TSN 101, and in case > > 102 is abandoned at this point (but 101 is not), > > Now wait... no I mis-understand your diagram.. you are not > skipping 101, but 102... > > So at the point the T3-Timer goes off you have > > 101-- still good need resend > 102-- mark to abandon > 103-- Acked with gap-acks > > In this case your advanced peer ack point will still be > at 100 (the same as the cum-ack) so you can NOT send > a fwd-tsn.. Yes, you are right... I had the idea that you could also report abandoned TSNs which are earlier than the Cumulative TSN ACK... Some kind of abandoned TSNs Gaps as in the SACK or so... I'm mistaken here... However, does it make any sense having such "gaps"? Probably not, since in this case you directly send a DATA, not a FORWARD TSN... :-/ > Not until the SACK(101) comes back and then your adv-peer-ack-point > will be advanced. > > Note rule C2) and also note rule C3).. so in the first > case C2 prevents you from moving a-p-a since 101 is still > outstanding and is not marked to skip.. and C3) blocks > you from sending a FWD-TSN since the a-p-a is equal to > your Cum-Ack. Yep... For a moment I was thinking about those Stream Numbers as specifying the SSNs that were abandoned... even past the Cumulative TSN ACK... > In the second case (after SACK(101) arrives) you then > can, by C2) set a-p-a to 102 and thus send a fwd-tsn.. > > I think there is nothing wrong with discarding > old FWD-TSN's .. you may want to handle them the > same way you would duplcaite data though.. and send a > SACK().. > > > > the "New Cumulative > > TSN" of the FORWARD TSN chunk will be set to 100, > > and won't be sent (see above) Yes... > however, the > > Cumulative TSN at the receiver is already 101, and the information > > carried in the FORWARD TSN chunk would help the data > receiver advance > > its Cumulative TSN to at least 103... > > > > Hmm... I don't think this rule is valid... :-/ > > Please restate your example... if I missed something... I think > its ok.. No, you got it right, I was mistaken... > > - Section 4.3, beginning of page 18: Typo. "...) than those > > additional..." should be "...) then those additional..." > > got it. > > > > > - Section 6: I guess there is a period missing at the end, between > > "security" and "further"... > > > > > > I think this is enough this time :-) > > I will put a new diff (against -03 up with your new changes in :>) Thanks! BR Iván Arias Rodríguez > R > > > > > > Thanks! > > > > BR Iván Arias Rodríguez > > _______________________________________________ tsvwg mailing list > > tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg > > > > > > > -- > Randall R. Stewart > randall@stewart.chicago.il.us 815-342-5222 (cell phone) > > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu May 8 11:44:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27359 for ; Thu, 8 May 2003 11:44:45 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h48FsHI23507 for tsvwg-archive@odin.ietf.org; Thu, 8 May 2003 11:54:17 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h48Fqf823331; Thu, 8 May 2003 11:52:41 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h48Fj8822802 for ; Thu, 8 May 2003 11:45:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26843 for ; Thu, 8 May 2003 11:35:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DnSI-0003az-00 for tsvwg@ietf.org; Thu, 08 May 2003 11:37:10 -0400 Received: from stewart.chicago.il.us ([66.93.186.36]) by ietf-mx with esmtp (Exim 4.12) id 19DnSG-0003ae-00 for tsvwg@ietf.org; Thu, 08 May 2003 11:37:08 -0400 Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8p1/8.12.8) with ESMTP id h48Fb8rf007762; Thu, 8 May 2003 10:37:09 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3EBA79A3.7040100@stewart.chicago.il.us> Date: Thu, 08 May 2003 10:37:08 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3) Gecko/20030502 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ivan.Arias-Rodriguez@nokia.com CC: tsvwg@ietf.org Subject: Re: [Tsvwg] Comments about prsctp-03.txt (and latest changes) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by stewart.chicago.il.us id h48Fb8rf007762 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h48Fj8822803 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Ivan.Arias-Rodriguez@nokia.com wrote: > >>> By the way, the graphic at the beginning of the page shows >>> "*Steam* Sequence-1"... >> >> Yes.. and it is labeld >> >> Stream Sequence-N >> >> and so the graphic shows Stream Sequence-1 >> >> Is this not what one would expect... if we want to kill the word >> stream thats ok.. I just don't understand why you need to.. it is >> after all a "stream sequence" number... > > > The point is that there is an "r" missing. It says "Steam" instead of > "Stream"... > > I guess that steam was going out of your head trying to figure out > what I was meaning... ;-) > Ahh..I missed the R a second time :> either that or I was thinking of trains :> > >>> - Section 3.3.3, beginning of 10th page: Forgive me for this >>> comment but, what about gracefully closing the association? Later >>> in this section, in 2) there is a typo: "reliablilty". >> >> Got the reliablity...but if you are just starting the association >> I.e. have either sent the INIT or received it... there is NO >> association to gracefully close.. so one would abort it not close >> it.. > > > Yes, in that case. But it says that the "... initiation process have > already ended..." > > But it is a little silly comment from mine anyway... :-0 > > BTW, shouldn't it say "... initiation process *has* already > ended..."? > Yep.. but maybe the whole statment in () should be killed... don't know why I said already finished...because it could not have :> > >> Otherwise one would need to finish the 4-way handshake and THEN >> shut it down.. which makes no sense to me...am I missing something? >> > > > Well... read above... > > >>> - Section 3.4, A2): It doesn't say here anything about updating >>> the Advanced.Peer.Ack.Point, should >> >> Good point.. you should try to advance the ack point if possible as >> well as resend a new fwd-tsn. >> >> >> >>> - Section 3.4, C4): It says "drop's" here, I guess it could be... >>> "abandonings"? There are another two "drop"s in section 4.1 TR3) >>> and TR4). >>> >> >> Ok, got them.. even though I think abandonings is a bit strange.. I >> > > > Yep... Well, it is you whose mother tongue is English, so... :-) Well, that is something that as always haunted me.. but there is nothing I can do about it but muddle through :D > > >> can't think of any other way to word it :> >> >>> - Section 3.6, first paragraph: Should the "end point" written >>> here be "endpoint" instead? >>> >> >> Yep thats a typo. >> >> >>> - Section 3.6, page 14: There is here a rule to treat a FORWARD >>> TSN as out-of-date and discard it, but I'm not convinced it is >>> right... >>> >>> Imagine the sender has sent TSNs 101, 102 and 103. TSN 103 >>> arrived normally, 102 was lost in the network, and 101 was >>> delayed enough time to make the T3 timer expire and send the >>> FORWARD TSN chunk before the SACK reached the data sender. >> >> So let me get this right >> >> CUM-ACK=100 >> >> I send >> >> ---TSN101--->Xdelayed ---TSN102--->Xlost >> ---TSN103--------------------------> <-------------SACK(100, >> got103-103)--- Now t3-rxt goes off on 101 so I >> >> ----FORWARD-TSN(101)--------> >> >>> If the sender has not received yet the SACK for TSN 101, and in >>> case 102 is abandoned at this point (but 101 is not), >> >> Now wait... no I mis-understand your diagram.. you are not skipping >> 101, but 102... >> >> So at the point the T3-Timer goes off you have >> >> 101-- still good need resend 102-- mark to abandon 103-- Acked with >> gap-acks >> >> In this case your advanced peer ack point will still be at 100 (the >> same as the cum-ack) so you can NOT send a fwd-tsn.. > > > Yes, you are right... I had the idea that you could also report > abandoned TSNs which are earlier than the Cumulative TSN ACK... Some > kind of abandoned TSNs Gaps as in the SACK or so... Not sure why one wuuld need this.. since once the cum-ack is passed it is done... > > I'm mistaken here... However, does it make any sense having such > "gaps"? Probably not, since in this case you directly send a DATA, > not a FORWARD TSN... :-/ I don't think you need them... > > >> Not until the SACK(101) comes back and then your adv-peer-ack-point >> will be advanced. >> >> Note rule C2) and also note rule C3).. so in the first case C2 >> prevents you from moving a-p-a since 101 is still outstanding and >> is not marked to skip.. and C3) blocks you from sending a FWD-TSN >> since the a-p-a is equal to your Cum-Ack. > > > Yep... For a moment I was thinking about those Stream Numbers as > specifying the SSNs that were abandoned... even past the Cumulative > TSN ACK... ok > > >> In the second case (after SACK(101) arrives) you then can, by C2) >> set a-p-a to 102 and thus send a fwd-tsn.. >> >> I think there is nothing wrong with discarding old FWD-TSN's .. you >> may want to handle them the same way you would duplcaite data >> though.. and send a SACK().. >> >> >> >> the "New Cumulative >> >>> TSN" of the FORWARD TSN chunk will be set to 100, >> >> and won't be sent (see above) > > > Yes... > > >> however, the >> >>> Cumulative TSN at the receiver is already 101, and the >>> information carried in the FORWARD TSN chunk would help the data >>> >> >> receiver advance >> >>> its Cumulative TSN to at least 103... >>> >>> Hmm... I don't think this rule is valid... :-/ >> >> Please restate your example... if I missed something... I think its >> ok.. > > > No, you got it right, I was mistaken... > A bit of steam got in the way here too :-D > >>> - Section 4.3, beginning of page 18: Typo. "...) than those >>> additional..." should be "...) then those additional..." >> >> got it. >> >> >>> - Section 6: I guess there is a period missing at the end, >>> between "security" and "further"... >> >> >>> I think this is enough this time :-) >> >> I will put a new diff (against -03 up with your new changes in :>) > > > Thanks! I will fix the steam but I will not put an updated change on the web site.. Let me know if you have trouble accessing it.. you shoudl be ok but one never knows :> R > > BR Iván Arias Rodríguez > > >> R >> >> >> >>> Thanks! >>> >>> BR Iván Arias Rodríguez >>> _______________________________________________ tsvwg mailing >>> list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg >>> >>> >> >> >> -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 >> (cell phone) >> >> > > > > -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu May 8 13:30:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00932 for ; Thu, 8 May 2003 13:30:50 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h48HeNO01507 for tsvwg-archive@odin.ietf.org; Thu, 8 May 2003 13:40:23 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h48Hd1801435; Thu, 8 May 2003 13:39:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h48HYZ800367 for ; Thu, 8 May 2003 13:34:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00810 for ; Thu, 8 May 2003 13:24:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DpAB-0004VF-00 for tsvwg@ietf.org; Thu, 08 May 2003 13:26:35 -0400 Received: from joda.cis.temple.edu ([155.247.71.60] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19DpAA-0004VC-00 for tsvwg@ietf.org; Thu, 08 May 2003 13:26:34 -0400 Received: from BLUEHEN.acm.org (bluehen.cis.temple.edu [155.247.182.8]) by joda.cis.temple.edu (8.9.3/8.9.3) with ESMTP id NAA02586; Thu, 8 May 2003 13:27:18 -0400 (EDT) Message-Id: <5.1.0.14.2.20030508132141.03853e90@joda.cis.temple.edu> X-Sender: conrad@joda.cis.temple.edu X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 08 May 2003 13:32:36 -0400 To: Ivan.Arias-Rodriguez@nokia.com, From: "Phillip T. Conrad" Subject: RE: [Tsvwg] Comments about prsctp-03.txt (and latest changes) Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , At 05:46 PM 5/8/2003 +0300, Ivan.Arias-Rodriguez@nokia.com wrote: > > > - Section 3.4, C4): It says "drop's" here, I guess it could be... > > > "abandonings"? There are another two "drop"s in section 4.1 TR3) and > > > TR4). > > > > > Ok, got them.. even though I think abandonings is a bit strange.. I > > Yep... Well, it is you whose mother tongue is English, so... :-) > > > can't think of any other way to word it :> How about "abadonments", or better yet "abandoned messages" "abandonded chunks" In context: Each stream SHOULD only be reported once; this means that if multiple abandoned messages occur in the same stream then only the highest abandoned stream sequence number is reported. Note also that the punctuation after the word "once" should be a semicolon (;) rather than a comma; this is because you are linking two complete sentences without the use of "and", "or", or "but". Cheers, Phill (who recently met again his high school english teacher after 22 years and thanked her profusely) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue May 13 13:20:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20902 for ; Tue, 13 May 2003 13:20:08 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4DGkFq11157 for tsvwg-archive@odin.ietf.org; Tue, 13 May 2003 12:46:15 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DGiOB11023; Tue, 13 May 2003 12:44:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DGgfB10968 for ; Tue, 13 May 2003 12:42:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20780 for ; Tue, 13 May 2003 13:16:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FdPc-00066K-00 for tsvwg@ietf.org; Tue, 13 May 2003 13:18:00 -0400 Received: from cougar.icir.org ([192.150.187.76]) by ietf-mx with esmtp (Exim 4.12) id 19FdPb-00066H-00 for tsvwg@ietf.org; Tue, 13 May 2003 13:17:59 -0400 Received: from cougar.icir.org (localhost [127.0.0.1]) by cougar.icir.org (8.12.8p1/8.12.3) with ESMTP id h4DHJ3vo079598; Tue, 13 May 2003 10:19:03 -0700 (PDT) (envelope-from floyd@cougar.icir.org) Message-Id: <200305131719.h4DHJ3vo079598@cougar.icir.org> To: tsvwg@ietf.org cc: Tom Henderson From: Sally Floyd Date: Tue, 13 May 2003 10:19:03 -0700 Subject: [Tsvwg] taking NewReno (RFC 2582) to Proposed Standard Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Tom Henderson and I have modified RFC 2582, the NewReno RFC, as the first step towards taking it from Experimental to Proposed Standard. This is not yet an official work item of tsvwg, but we did discuss it briefly at the tsvwg meeting in San Francisco. The new draft is at: http://www.ietf.org/internet-drafts/draft-floyd-newreno-00.txt The slides from the presentation-that-was-skipped-due-to-time in San Francisco are at: http://www.icir.org/floyd/talks.html There are no changes to the underlying NewReno algorithm. The main change in the draft is that RFC 2582 desribed several variants regarding avoiding unnecessary Fast Retransmits, and *recommended* the Careful variant, while the new draft only specifies the Careful variant. Any feedback would be appreciated. - Sally and Tom Here are the changes in the draft: NOTE TO THE RFC EDITOR: PLEASE REMOVE THIS SECTION UPON PUBLICATION. Changes from RFC 2582: * Rephrasing and rearrangements of the text. * RFC 2582 described the Careful and Less Careful variants of NewReno, along with a default version that was neither Careful nor Less Careful, and recommended the Careful variant. This document only specifies the Careful version. * RFC 2582 used two separate variables, "send_high" and "recover", and this document has merged them into a single variable "recover". * Added sections on "Comparisons between Reno and NewReno TCP", and on "Changes relative to RFC 2582". The section on "Comparisons between Reno and NewReno TCP" includes a discussion of the one area where NewReno is known to perform worse than Reno or SACK, and that is in the response to reordering. * Moved all of the discussions of the Impatient and Slow-but-Steady variants to one place, and specified the Impatient variant (as in the default version in RFC 2582). * Added a section on Implementation issues for the data sender, mentioning maxburst_. * Added a paragraph about differences between RFC 2582 and [FF96]. END OF NOTE TO RFC EDITOR _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue May 13 13:53:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22226 for ; Tue, 13 May 2003 13:53:24 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4DHJV113703 for tsvwg-archive@odin.ietf.org; Tue, 13 May 2003 13:19:31 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DHGCB13572; Tue, 13 May 2003 13:16:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DHFmB13533 for ; Tue, 13 May 2003 13:15:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22089 for ; Tue, 13 May 2003 13:49:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Fdve-0006Kp-00 for tsvwg@ietf.org; Tue, 13 May 2003 13:51:06 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 19Fdvd-0006Km-00 for tsvwg@ietf.org; Tue, 13 May 2003 13:51:05 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id E63A2328F3; Tue, 13 May 2003 13:52:10 -0400 (EDT) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id C22453292B; Tue, 13 May 2003 13:52:09 -0400 (EDT) Date: Tue, 13 May 2003 13:52:09 -0400 (EDT) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: Sally Floyd Cc: , Tom Henderson Subject: Re: [Tsvwg] taking NewReno (RFC 2582) to Proposed Standard In-Reply-To: <200305131719.h4DHJ3vo079598@cougar.icir.org> Message-ID: X-Spam-Status: No, hits=-5.3 required=6.0 tests=DEPT_RCVD,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.43 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , On Tue, 13 May 2003, Sally Floyd wrote: > Tom Henderson and I have modified RFC 2582, the NewReno RFC, > as the first step towards taking it from Experimental to > Proposed Standard. This is not yet an official work item of tsvwg, > but we did discuss it briefly at the tsvwg meeting in San Francisco. > Here are the changes in the draft: > * Added a section on Implementation issues for the data sender, > mentioning maxburst_. I am not sure if it is appropriate, but I think it would be useful to suggest using the Congestion Window Validation (RFC 2861) technique instead of the simple maxburst_ limit. ~armando 0-- --0 | Armando L. Caro Jr. | Protocol Engineering Lab | | www.cis.udel.edu/~acaro | University of Delaware | 0-- --0 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue May 13 14:03:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22733 for ; Tue, 13 May 2003 14:03:28 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4DHTaF14358 for tsvwg-archive@odin.ietf.org; Tue, 13 May 2003 13:29:36 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DHSBB14291; Tue, 13 May 2003 13:28:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DHRVB14256 for ; Tue, 13 May 2003 13:27:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22602 for ; Tue, 13 May 2003 14:00:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Fe6z-0006S0-00 for tsvwg@ietf.org; Tue, 13 May 2003 14:02:49 -0400 Received: from cougar.icir.org ([192.150.187.76]) by ietf-mx with esmtp (Exim 4.12) id 19Fe6y-0006Rx-00 for tsvwg@ietf.org; Tue, 13 May 2003 14:02:48 -0400 Received: from cougar.icir.org (localhost [127.0.0.1]) by cougar.icir.org (8.12.8p1/8.12.3) with ESMTP id h4DI3qvo080059; Tue, 13 May 2003 11:03:52 -0700 (PDT) (envelope-from floyd@cougar.icir.org) Message-Id: <200305131803.h4DI3qvo080059@cougar.icir.org> To: "Armando L. Caro Jr." cc: tsvwg@ietf.org, Tom Henderson From: Sally Floyd Subject: Re: [Tsvwg] taking NewReno (RFC 2582) to Proposed Standard Date: Tue, 13 May 2003 11:03:52 -0700 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , >> * Added a section on Implementation issues for the data sender, >> mentioning maxburst_. > >I am not sure if it is appropriate, but I think it would be useful to >suggest using the Congestion Window Validation (RFC 2861) technique >instead of the simple maxburst_ limit. Actually, they serve rather different purposes. Congestion Window Validation (RFC 2861) is about how the sender reduces the congestion window after an idle or application-limited period, when the sender was not using the full value of the old congestion window. This is orthogonal to NewReno. Maxburst_ is mentioned in the new NewReno draft for dealing with the burstiness that can result when the sender exits Fast Recovery. And the NewReno draft specifies a method for setting cwnd that should avoid this burstiness in the first place, in step (5) of Section 3. - Sally http://www.icir.org/floyd/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue May 13 18:25:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02309 for ; Tue, 13 May 2003 18:25:09 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4DLpLe02711 for tsvwg-archive@odin.ietf.org; Tue, 13 May 2003 17:51:21 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DLo1B02443; Tue, 13 May 2003 17:50:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DLWbB00632 for ; Tue, 13 May 2003 17:32:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00882 for ; Tue, 13 May 2003 18:05:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Fhw5-0000Ca-00 for tsvwg@ietf.org; Tue, 13 May 2003 18:07:49 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 19Fhw5-0000CX-00 for tsvwg@ietf.org; Tue, 13 May 2003 18:07:49 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 6AD0B328FA; Tue, 13 May 2003 18:08:55 -0400 (EDT) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id 741E5328F5; Tue, 13 May 2003 18:08:54 -0400 (EDT) Date: Tue, 13 May 2003 18:08:54 -0400 (EDT) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: Sally Floyd Cc: , Tom Henderson Subject: Re: [Tsvwg] taking NewReno (RFC 2582) to Proposed Standard In-Reply-To: <200305131803.h4DI3qvo080059@cougar.icir.org> Message-ID: X-Spam-Status: No, hits=-4.7 required=6.0 tests=DEPT_RCVD,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_03_05,USER_AGENT_PINE version=2.43 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , On Tue, 13 May 2003, Sally Floyd wrote: > >> * Added a section on Implementation issues for the data sender, > >> mentioning maxburst_. > > > >I am not sure if it is appropriate, but I think it would be useful to > >suggest using the Congestion Window Validation (RFC 2861) technique > >instead of the simple maxburst_ limit. > > Actually, they serve rather different purposes. Yes, I understand that... > Congestion Window Validation (RFC 2861) is about how the sender > reduces the congestion window after an idle or application-limited > period, when the sender was not using the full value of the old > congestion window. This is orthogonal to NewReno. > Maxburst_ is mentioned in the new NewReno draft for dealing > with the burstiness that can result when the sender exits > Fast Recovery. And the NewReno draft specifies a method for > setting cwnd that should avoid this burstiness in the first place, > in step (5) of Section 3. I don't think CWV is completely orthogonal to NewReno's burst limitation, but I could have been more clear in my original mail. My reference to CWV was specific to a particular portion of RFC 2861 (Section 3.2, "If no more data is available to send"). The non-maxburst algorithm that you pointed out in the NewReno draft's Section 3 - step 5 is the kind of burst limitation algorithm I had in mind when writing my original mail... I must admit that I somehow missed that part when reading the draft. Also I notice now that CWV isn't as similar as I had remembered. Sorry, my mistake. Anyway, is there a reason to leave the two burst limitation methods in the draft? One method is to cap the cwnd after Fast Recover only by setting cwnd = min (ssthresh, FlightSize + SMSS). The other method is to apply a limit (maxburst) on "the number of data packets that can be sent in response to a single acknowledgement". Why not combine the two (as done in the SCTP implementer's guide) into a simple algorithm as follows? if((flightsize + Max.Burst*SMSS) < cwnd) cwnd = flightsize + Max.Burst*SMSS ~armando 0-- --0 | Armando L. Caro Jr. | Protocol Engineering Lab | | www.cis.udel.edu/~acaro | University of Delaware | 0-- --0 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue May 13 20:59:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05703 for ; Tue, 13 May 2003 20:59:13 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4E0PUZ13356 for tsvwg-archive@odin.ietf.org; Tue, 13 May 2003 20:25:30 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4E0OHB13320; Tue, 13 May 2003 20:24:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4E0NBB13284 for ; Tue, 13 May 2003 20:23:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05665 for ; Tue, 13 May 2003 20:56:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Fkb7-0001D5-00 for tsvwg@ietf.org; Tue, 13 May 2003 20:58:21 -0400 Received: from relay4.tp1rc.edu.tw ([163.28.16.34]) by ietf-mx with esmtp (Exim 4.12) id 19Fkb6-0001D2-00 for tsvwg@ietf.org; Tue, 13 May 2003 20:58:20 -0400 Received: from KHL (61-219-40-1.HINET-IP.hinet.net [61.219.40.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by relay4.tp1rc.edu.tw (Postfix) with ESMTP id 4E30D8FBF1 for ; Wed, 14 May 2003 08:59:25 +0800 (CST) Message-ID: <00ef01c319b4$eba7b470$6ec5900a@saoe.com> From: "Ling-Chih Kao" To: "SCTP" Date: Wed, 14 May 2003 09:05:31 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00EC_01C319F7.F86263C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [Tsvwg] (no subject) Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_00EC_01C319F7.F86263C0 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable Hi,=20 1.=20 In the definition of RFC 2960, two SCTP endpoints MUST NOT have more = than one SCTP association between them at any given time. A host can configure into more than one SCTP assocations; therefore, two Host can have more than one SCTP associations between them. Is this statement correct? 2. If SG accept 10000 call setup siganl from SS7, and the SG establish a = SCTP association for these calls to a AS. Some of the calls may be completed early, so the streams in the = assocaition for these calls are idle.=20 Can this idle streams be used for new SS7 setup calls? Or, new SS7 setup = call must establish their new SCTP association. Thanks Ling-Chih Kao ------=_NextPart_000_00EC_01C319F7.F86263C0 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable
Hi,
 
1.
In the definition of RFC 2960, two SCTP endpoints = MUST NOT=20 have more than one SCTP association between them at any given=20 time.
 
A host can configure into more than one SCTP = assocations;=20 therefore,
two Host can have more than one SCTP associations = between=20 them.
Is this statement correct?
 
2.
If SG accept 10000 call setup siganl from SS7, = and the=20 SG establish a SCTP association for these calls to a = AS.
Some of the calls may be completed early, so the = streams in=20 the assocaition for these calls are idle.
Can this idle streams be used for new SS7 setup = calls? Or, new=20 SS7 setup call must establish their new SCTP association.
 
Thanks
 
Ling-Chih=20 Kao
------=_NextPart_000_00EC_01C319F7.F86263C0-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue May 13 21:09:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05881 for ; Tue, 13 May 2003 21:09:19 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4E0Zae13792 for tsvwg-archive@odin.ietf.org; Tue, 13 May 2003 20:35:36 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4E0Y6B13705; Tue, 13 May 2003 20:34:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4E0X6B13660 for ; Tue, 13 May 2003 20:33:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05822 for ; Tue, 13 May 2003 21:06:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Fkkh-0001GV-00 for tsvwg@ietf.org; Tue, 13 May 2003 21:08:15 -0400 Received: from relay4.tp1rc.edu.tw ([163.28.16.34]) by ietf-mx with esmtp (Exim 4.12) id 19Fkkg-0001GS-00 for tsvwg@ietf.org; Tue, 13 May 2003 21:08:15 -0400 Received: from KHL (61-219-40-1.HINET-IP.hinet.net [61.219.40.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by relay4.tp1rc.edu.tw (Postfix) with ESMTP id 88C548FD41 for ; Wed, 14 May 2003 09:09:20 +0800 (CST) Message-ID: <010c01c319b6$4e654db0$6ec5900a@saoe.com> From: "Ling-Chih Kao" To: "SCTP" Date: Wed, 14 May 2003 09:15:25 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0109_01C319F9.5AC5CF10" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [Tsvwg] question about SCTP Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0109_01C319F9.5AC5CF10 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable Hi,=20 1.=20 In the definition of RFC 2960, two SCTP endpoints MUST NOT have more = than one SCTP association between them at any given time. A host can configure into more than one SCTP assocations; therefore, two Host can have more than one SCTP associations between them. Is this statement correct? 2. If SG accept 10000 call setup siganl from SS7, and the SG establish a = SCTP association for these calls to a AS. Some of the calls may be completed early, so the streams in the = assocaition for these calls are idle.=20 Can this idle streams be used for new SS7 setup calls? Or, new SS7 call = setup must establish their new SCTP association. Thanks Ling-Chih Kao ------=_NextPart_000_0109_01C319F9.5AC5CF10 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable
Hi,
 
1.
In the definition of RFC 2960, two SCTP endpoints = MUST NOT=20 have more than one SCTP association between them at any given=20 time.
 
A host can configure into more than one SCTP = assocations;=20 therefore,
two Host can have more than one SCTP associations = between=20 them.
Is this statement correct?
 
2.
If SG accept 10000 call setup siganl from SS7, = and the=20 SG establish a SCTP association for these calls to a = AS.
Some of the calls may be completed early, so the = streams in=20 the assocaition for these calls are idle.
Can this idle streams be used for new SS7 setup = calls? Or, new=20 SS7 call setup must establish their new SCTP association.
 
Thanks
 
Ling-Chih=20 Kao
------=_NextPart_000_0109_01C319F9.5AC5CF10-- _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed May 14 00:01:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08782 for ; Wed, 14 May 2003 00:01:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4E3RPL25553 for tsvwg-archive@odin.ietf.org; Tue, 13 May 2003 23:27:25 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4E3PcB25492; Tue, 13 May 2003 23:25:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4E3OxB25447 for ; Tue, 13 May 2003 23:24:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08719 for ; Tue, 13 May 2003 23:58:09 -0400 (EDT) From: rezhirpavai@hss.hns.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FnQy-00026k-00 for tsvwg@ietf.org; Wed, 14 May 2003 00:00:04 -0400 Received: from hindon.hss.co.in ([202.54.26.202]) by ietf-mx with esmtp (Exim 4.12) id 19FnQx-00026X-00 for tsvwg@ietf.org; Wed, 14 May 2003 00:00:03 -0400 Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h4E3w9o08187 for ; Wed, 14 May 2003 09:28:09 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h4E3w7908153; Wed, 14 May 2003 09:28:07 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id h4E41Js22618; Wed, 14 May 2003 09:31:19 +0530 (IST) Subject: Re: [Tsvwg] question about SCTP To: "Ling-Chih Kao" Cc: "SCTP" Date: Wed, 14 May 2003 09:26:52 +0530 Message-ID: X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 14/05/2003 09:25:51 AM MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4E3OxB25448 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hello, Response Embedded: Regards, - R. Ezhirpavai Hughes Software Systems, India. http://www.hssworld.com "Ling-Chih Kao" @ietf.org on 05/14/2003 06:45:25 AM Sent by: tsvwg-admin@ietf.org To: "SCTP" cc: Subject: [Tsvwg] question about SCTP Hi, 1. In the definition of RFC 2960, two SCTP endpoints MUST NOT have more than one SCTP association between them at any given time. A host can configure into more than one SCTP assocations; therefore, two Host can have more than one SCTP associations between them. Is this statement correct? [RE]-> Theoretically, yes this is correct, but one could use the multi-homing feature to use the multiple IP addresses and  multi-streaming feature to differentiate different logical streams. 2. If SG accept 10000 call setup siganl from SS7, and the SG establish a SCTP association for these calls to a AS. Some of the calls may be completed early, so the streams in the assocaition for these calls are idle. Can this idle streams be used for new SS7 setup calls? Or, new SS7 call setup must establish their new SCTP association. [RE]-> If you are taking of M3UA above SCTP, then one would not have one stream per call. Each SLS could be one different stream and thus stream would not dynamically increase or decrease. The streams would carry ISUP messages for all the calls that the ISUP decides to put on a particular SLS. Thanks Ling-Chih Kao _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed May 14 03:25:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08031 for ; Wed, 14 May 2003 03:25:41 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4E6q5A18049 for tsvwg-archive@odin.ietf.org; Wed, 14 May 2003 02:52:05 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4E6oRB17959; Wed, 14 May 2003 02:50:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4E6nAB17894 for ; Wed, 14 May 2003 02:49:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07849 for ; Wed, 14 May 2003 03:22:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FqcV-0003H8-00 for tsvwg@ietf.org; Wed, 14 May 2003 03:24:11 -0400 Received: from parmesan.cs.wisc.edu ([128.105.167.16]) by ietf-mx with esmtp (Exim 4.12) id 19FqcV-0003H2-00 for tsvwg@ietf.org; Wed, 14 May 2003 03:24:11 -0400 Received: (from poon@localhost) by parmesan.cs.wisc.edu (8.9.2/8.9.2) id CAA23417 for tsvwg@ietf.org; Wed, 14 May 2003 02:25:18 -0500 (CDT) Date: Wed, 14 May 2003 02:25:18 -0500 (CDT) From: Kacheong Poon Message-Id: <200305140725.CAA23417@parmesan.cs.wisc.edu> To: tsvwg@ietf.org Subject: Re: [Tsvwg] taking NewReno (RFC 2582) to Proposed Standard Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Included message from "Armando L. Caro Jr." : >---- >Anyway, is there a reason to leave the two burst limitation methods in the >draft? One method is to cap the cwnd after Fast Recover only by setting >cwnd = min (ssthresh, FlightSize + SMSS). The other method is to apply a >limit (maxburst) on "the number of data packets that can be sent in >response to a single acknowledgement". Why not combine the two (as done >in the SCTP implementer's guide) into a simple algorithm as follows? > >if((flightsize + Max.Burst*SMSS) < cwnd) > cwnd = flightsize + Max.Burst*SMSS >---- I believe step 5 in section 3 is for setting the cwnd so that after Fast Recovery, the sending rate is at most half of the previous one. If the above formula is used, cwnd will be wrong. For example, if flightsize happens to be 0 (no new TCP segment is sent during Fast Revoery), cwnd will be Max.Burst * SMSS regardless of what the previous sending rate is. But using step 5 in section 3, it will be just 1 SMSS or ssthresh, which is the intended value. The note in the draft says that if sshthresh is used, maxburst_ should probably be there to avoid burstiness. They are for different purposes. I believe the reason why you don't see these written in RFC 2960 and the implementer's guide draft is just that the algorithm is described differently. Instead of "manipulating" cwnd to force sending of new segments in TCP, RFC 2960 just says send new data if allowed by cwnd, and calculation of cwnd already takes the above into account. Different wording, same idea... K. Poon. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed May 14 07:54:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13434 for ; Wed, 14 May 2003 07:54:33 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4EBL2Z05357 for tsvwg-archive@odin.ietf.org; Wed, 14 May 2003 07:21:02 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4EBJYB05258; Wed, 14 May 2003 07:19:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4EBIFB05205 for ; Wed, 14 May 2003 07:18:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13397 for ; Wed, 14 May 2003 07:51:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Fuoo-0004hr-00 for tsvwg@ietf.org; Wed, 14 May 2003 07:53:10 -0400 Received: from stewart.chicago.il.us ([66.93.186.36]) by ietf-mx with esmtp (Exim 4.12) id 19Fuoo-0004hb-00 for tsvwg@ietf.org; Wed, 14 May 2003 07:53:10 -0400 Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8p1/8.12.8) with ESMTP id h4EBrRrf054305; Wed, 14 May 2003 06:53:42 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3EC22E37.70009@stewart.chicago.il.us> Date: Wed, 14 May 2003 06:53:27 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3b) Gecko/20030323 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ling-Chih Kao CC: SCTP Subject: Re: [Tsvwg] question about SCTP References: <010c01c319b6$4e654db0$6ec5900a@saoe.com> In-Reply-To: <010c01c319b6$4e654db0$6ec5900a@saoe.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ling-Chih: Comments in line... Ling-Chih Kao wrote: > Hi, > > 1. > In the definition of RFC 2960, two SCTP endpoints MUST NOT have more > than one SCTP association between them at any given time. > > A host can configure into more than one SCTP assocations; therefore, > two Host can have more than one SCTP associations between them. > Is this statement correct? > Yes, this is correct. To make it a real simple process think in terms of TCP.. One can have a connection between two TCP endpoints say: Port:1111 IP-A <------------------------->Port:1112 IP-Z But one cannot have TWO seperate connections between the same ports/host .. so you can't duplicate the above and have two seperate connections identical.. The same is true for SCTP.. The only difference is that the seperate sides may have more than one IP address i.e.: Port:1111 IP-A1,IP-A2,IP-A3 <-------------->Port:1112 IP-Z1, IP-Z2 this is the only difference... > 2. > If SG accept 10000 call setup siganl from SS7, and the SG establish > a SCTP association for these calls to a AS. > Some of the calls may be completed early, so the streams in the > assocaition for these calls are idle. > Can this idle streams be used for new SS7 setup calls? Or, new SS7 call > setup must establish their new SCTP association. > This one is more of a sigtran question. It is up to the ULP to decide how they will use the streams. One could envision doing as you say.. a stream for each call and then at the termination of a call reuse the stream for a new call.. however this MAY not be how sigtran specified the ULP's for the SS7 adaption.. you need to direct that question to the sigtran mailing list :> R > Thanks > > Ling-Chih Kao -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed May 14 09:37:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17455 for ; Wed, 14 May 2003 09:37:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4ED3l913127 for tsvwg-archive@odin.ietf.org; Wed, 14 May 2003 09:03:47 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4ED2SB13060; Wed, 14 May 2003 09:02:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4ED1oB13006 for ; Wed, 14 May 2003 09:01:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17423 for ; Wed, 14 May 2003 09:34:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FwR1-0005vC-00 for tsvwg@ietf.org; Wed, 14 May 2003 09:36:43 -0400 Received: from stewart.chicago.il.us ([66.93.186.36]) by ietf-mx with esmtp (Exim 4.12) id 19FwR0-0005uj-00 for tsvwg@ietf.org; Wed, 14 May 2003 09:36:43 -0400 Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8p1/8.12.8) with ESMTP id h4EDbHrf055084 for ; Wed, 14 May 2003 08:37:19 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3EC2468D.8030405@stewart.chicago.il.us> Date: Wed, 14 May 2003 08:37:17 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3b) Gecko/20030323 X-Accept-Language: en-us, en MIME-Version: 1.0 To: TSV WG list Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Tsvwg] Update to the changes for PRSCTP Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all: Once again I have updated all comments and changes to the PR-SCTP draft. Please have a look at the html at http://www.sctp.org under internet drafts you will find a link to the diff document.. Have a look and please send comments... I intend to submit this by Friday.. Thanks R -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed May 14 19:08:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09714 for ; Wed, 14 May 2003 19:08:26 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4EMZ8e25209 for tsvwg-archive@odin.ietf.org; Wed, 14 May 2003 18:35:08 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4EMXrB25160; Wed, 14 May 2003 18:33:53 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4EMWpB25121 for ; Wed, 14 May 2003 18:32:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09684 for ; Wed, 14 May 2003 19:05:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19G5LQ-0002AA-00 for tsvwg@ietf.org; Wed, 14 May 2003 19:07:32 -0400 Received: from cougar.icir.org ([192.150.187.76]) by ietf-mx with esmtp (Exim 4.12) id 19G5LP-0002A6-00 for tsvwg@ietf.org; Wed, 14 May 2003 19:07:31 -0400 Received: from cougar.icir.org (localhost [127.0.0.1]) by cougar.icir.org (8.12.8p1/8.12.3) with ESMTP id h4EN8Yvo097312; Wed, 14 May 2003 16:08:34 -0700 (PDT) (envelope-from floyd@cougar.icir.org) Message-Id: <200305142308.h4EN8Yvo097312@cougar.icir.org> To: "Armando L. Caro Jr." cc: tsvwg@ietf.org, Tom Henderson From: Sally Floyd Subject: Re: [Tsvwg] taking NewReno (RFC 2582) to Proposed Standard Date: Wed, 14 May 2003 16:08:34 -0700 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Armando - >The other method is to apply a >limit (maxburst) on "the number of data packets that can be sent in >response to a single acknowledgement". Why not combine the two (as done >in the SCTP implementer's guide) into a simple algorithm as follows? > >if((flightsize + Max.Burst*SMSS) < cwnd) > cwnd = flightsize + Max.Burst*SMSS Well, since you asked... I happen to think that the algorithm above, of reducing the congestion window as a method to limit transient bursts that would last a fraction of a round-trip time, is fatally flawed and should NEVER be used by a transport protocol. I am several months overdue to write a note to the Linux gang about this (it seems that the TCP implementation in Linux does this also), but here is the jist of it, if I did manage to get to it: (This note from some February 11 email of mine that was part of a conversation about this with Tom Kelly, Brian Tierney, and Matt Mathis. The email conversation was started because some cases of terrible performance of Linux TCP with HighSpeed TCP were tracked down to exactly this code, as I recall...) >To: Tom Kelly , Brian Tierney >cc: Matt Mathis >Bcc: >From: Sally Floyd >Subject: OtherReductionsCM >Date: Tue, 11 Feb 2003 15:32:12 -0800 >Sender: floyd@cougar.icir.org > >Brian and Tom - > >Here are my arguments why the code for OtherReductionsCM, >in tcp_moderate_cwnd(), should be removed from the Linux code base: > >* If there is reordering in the forward or reverse path, and an ack >arrives acknowledging more than three packets, then cwnd will be >reduced. This is not a robust response to reordering. The goal >is to make TCP more robust to reordering, not less robust. > >* If there are losses on the reverse path, and an ack arrives >acknowledging more than three packets, then cwnd will be reduced. >I think that congestion control for the reverse-path traffic would >be a good thing. However, I don't think this would be a good way >to achieve it. > >* It is common for ACKs to be "compressed" in the network, by >piling up in a queue. Assume that the receiver uses delayed acks, >so that each ack acknowledges two packets. If N such acks arrive >at the TCP sender back-to-back, for N > 1, and the host decides >to process two ack packets before invoking the TCP send routine >to send new packets, then when the host processes the second ACK, >tcp_moderate_cwnd() will result in the congestion window being >reduced. Thus, the only way to avoid OtherReductionsCM being >invoked would be for the TCP sender to fully process each ACK, >including sending new packets triggered by that ACK, before >processing subsequent ACKs. This doesn't leave the implementation >much flexibility. > >* After the sender retransmits a lost packet, the receiver is likely >to send an ACK acknowledging N packets, for N>3. When the sender >receives this ACK, then is it going to *again* reduce its congestion >window, from OtherReductionsCM? If so, this seems rather perverse to >me. > >* If the receiver for some unknown reason sends an acknowledgement >acknowledging more than 3 packets (and some receivers in fact don't >send an ack for every two packets, even though they should), >then the TCP sender will respond by reducing cwnd. Not too robust. > >* I imagine that there are other cases as well where >OtherReductionsCM will do undesirable things... > >And here is the caveat: > >I have only looked at the code on Brian's viewgraph, not in the Linux >source code, so I *could* be missing some critical piece of >information... > >- Sally - Sally http://www.icir.org/floyd/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed May 14 19:56:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10532 for ; Wed, 14 May 2003 19:56:43 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4ENNRY28440 for tsvwg-archive@odin.ietf.org; Wed, 14 May 2003 19:23:27 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4ENM9B28392; Wed, 14 May 2003 19:22:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4ENLKB28367 for ; Wed, 14 May 2003 19:21:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10493 for ; Wed, 14 May 2003 19:54:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19G66K-0002QB-00 for tsvwg@ietf.org; Wed, 14 May 2003 19:56:00 -0400 Received: from cougar.icir.org ([192.150.187.76]) by ietf-mx with esmtp (Exim 4.12) id 19G66J-0002Q8-00 for tsvwg@ietf.org; Wed, 14 May 2003 19:56:00 -0400 Received: from cougar.icir.org (localhost [127.0.0.1]) by cougar.icir.org (8.12.8p1/8.12.3) with ESMTP id h4ENv6vo097980; Wed, 14 May 2003 16:57:06 -0700 (PDT) (envelope-from floyd@cougar.icir.org) Message-Id: <200305142357.h4ENv6vo097980@cougar.icir.org> To: Kacheong Poon cc: tsvwg@ietf.org From: Sally Floyd Subject: Re: [Tsvwg] taking NewReno (RFC 2582) to Proposed Standard Date: Wed, 14 May 2003 16:57:06 -0700 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , >Could you send me the viewgraph of the trace you looked at? I'm >interested to see what the effects you mentioned are. Thanks. Brian Tierney reported terrible performance for TCP, with or without HighSpeed TCP, at the First International Workshop on Protocols for Fast Long-Distance Networks ("http://datatag.web.cern.ch/datatag/pfldnet2003/"). You can find his viewgraphs there. Matt Mathis and gang instrumented Web100 to report those congestion window reductions due to "OtherReductionsCM", and Brian determined that these "OtherReductionsCM" reductions were the cause of the poor performance that he was seeing. There were two places in the Linux code where congestion window reductions were triggered that were reported by Web100 as "OtherReductionsCM". One is the tcp_moderate_cwnd() call in tcp_input.c, as follows: /* CWND moderation, preventing bursts due to too big ACKs * in dubious situations. */ static __inline__ void tcp_moderate_cwnd(struct tcp_opt *tp) { tp->snd_cwnd = min(tp->snd_cwnd, tcp_packets_in_flight(tp)+tcp_max_burst(tp)); tp->snd_cwnd_stamp = tcp_time_stamp; } In my opinion, this is a serious bad idea if one is trying to run TCP in a high-delay, high-bandwidth environment, where large congestion windows are needed to take advantage of the available bandwidth. - Sally http://www.icir.org/floyd/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu May 15 21:14:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28864 for ; Thu, 15 May 2003 21:14:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4G0fUx17058 for tsvwg-archive@odin.ietf.org; Thu, 15 May 2003 20:41:30 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4G0dmB16971; Thu, 15 May 2003 20:39:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4G0Y2B15980 for ; Thu, 15 May 2003 20:34:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28811 for ; Thu, 15 May 2003 21:06:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19GThT-0003JA-00 for tsvwg@ietf.org; Thu, 15 May 2003 21:07:55 -0400 Received: from stewart.chicago.il.us ([66.93.186.36]) by ietf-mx with esmtp (Exim 4.12) id 19GThN-0003Ia-00 for tsvwg@ietf.org; Thu, 15 May 2003 21:07:49 -0400 Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8p1/8.12.8) with ESMTP id h4G17frf067851; Thu, 15 May 2003 20:07:42 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3EC439DC.9020302@stewart.chicago.il.us> Date: Thu, 15 May 2003 20:07:40 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3b) Gecko/20030323 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sally Floyd CC: "Armando L. Caro Jr." , tsvwg@ietf.org, Tom Henderson Subject: Re: [Tsvwg] taking NewReno (RFC 2582) to Proposed Standard References: <200305142308.h4EN8Yvo097312@cougar.icir.org> In-Reply-To: <200305142308.h4EN8Yvo097312@cougar.icir.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Sally: I have thought a bit on this and have worked out where things fall apart in the face of reordering.. but this leads me to ask a question.. Lets assume we do have drastic reordering that is effecting the network.. say something like -----10 segments outstanding----> and of course the reciver sends 5 acks (every other segment)... but worse case happens and you get <----ack5 <----ack4 <----ack3 <----ack2 <----ack1 Now the first ack that arrives acknowledges all of the 10 segments.. the next 4 are considered old and dropped... Using ABC we would advance our cwnd from 10 to 11. But if you apply the max burst you drop to 4.. real bummer :-< However what happens to the network now without some sort of burst limit? The sender is now suddenly able to spike out 11 segments of data. And I know this can't be a good thing :< From some testing I was doing on my local lan with some networks.. series of bursts like this surely caused drops in the routers.. I can even provide you with ethereal traces showing this... the packets would hit the wire in a burst of say 10 or so packets and by the second or third burst like that .. you would still see the packets on the wire.. but they would never get into the outgoing side of the router.. being dropped by the line cards... note these are not cheap routers aka they are not your standard home office stuff.... (I won't say whos they were but you can probably guess :>) Anyway.. my point is.. all hardware.. no matter how expensive has some constraints as to how much burstyness it can handle... thus if you don't cut down how many you can burst out at once you are going to hit a loss event and that will effect your performance more I think :< Maybe there is someway we can control the sending without killing the cwnd.. but then as Mark Allman as stated.. you get two control variables and that seems like it might lead to interaction and trouble??? ???? any thoughts on this??? R Sally Floyd wrote: > Armando - > > >>The other method is to apply a >>limit (maxburst) on "the number of data packets that can be sent in >>response to a single acknowledgement". Why not combine the two (as done >>in the SCTP implementer's guide) into a simple algorithm as follows? >> >>if((flightsize + Max.Burst*SMSS) < cwnd) >> cwnd = flightsize + Max.Burst*SMSS > > > Well, since you asked... > > I happen to think that the algorithm above, of reducing the congestion > window as a method to limit transient bursts that would last a > fraction of a round-trip time, is fatally flawed and should NEVER > be used by a transport protocol. > > I am several months overdue to write a note to the Linux gang about this > (it seems that the TCP implementation in Linux does this also), > but here is the jist of it, if I did manage to get to it: > > (This note from some February 11 email of mine that was part of a > conversation about this with Tom Kelly, Brian Tierney, and Matt > Mathis. The email conversation was started because some cases of > terrible performance of Linux TCP with HighSpeed TCP were tracked > down to exactly this code, as I recall...) > > >>To: Tom Kelly , Brian Tierney >>cc: Matt Mathis >>Bcc: >>From: Sally Floyd >>Subject: OtherReductionsCM >>Date: Tue, 11 Feb 2003 15:32:12 -0800 >>Sender: floyd@cougar.icir.org >> >>Brian and Tom - >> >>Here are my arguments why the code for OtherReductionsCM, >>in tcp_moderate_cwnd(), should be removed from the Linux code base: >> >>* If there is reordering in the forward or reverse path, and an ack >>arrives acknowledging more than three packets, then cwnd will be >>reduced. This is not a robust response to reordering. The goal >>is to make TCP more robust to reordering, not less robust. >> >>* If there are losses on the reverse path, and an ack arrives >>acknowledging more than three packets, then cwnd will be reduced. >>I think that congestion control for the reverse-path traffic would >>be a good thing. However, I don't think this would be a good way >>to achieve it. >> >>* It is common for ACKs to be "compressed" in the network, by >>piling up in a queue. Assume that the receiver uses delayed acks, >>so that each ack acknowledges two packets. If N such acks arrive >>at the TCP sender back-to-back, for N > 1, and the host decides >>to process two ack packets before invoking the TCP send routine >>to send new packets, then when the host processes the second ACK, >>tcp_moderate_cwnd() will result in the congestion window being >>reduced. Thus, the only way to avoid OtherReductionsCM being >>invoked would be for the TCP sender to fully process each ACK, >>including sending new packets triggered by that ACK, before >>processing subsequent ACKs. This doesn't leave the implementation >>much flexibility. >> >>* After the sender retransmits a lost packet, the receiver is likely >>to send an ACK acknowledging N packets, for N>3. When the sender >>receives this ACK, then is it going to *again* reduce its congestion >>window, from OtherReductionsCM? If so, this seems rather perverse to >>me. >> >>* If the receiver for some unknown reason sends an acknowledgement >>acknowledging more than 3 packets (and some receivers in fact don't >>send an ack for every two packets, even though they should), >>then the TCP sender will respond by reducing cwnd. Not too robust. >> >>* I imagine that there are other cases as well where >>OtherReductionsCM will do undesirable things... >> >>And here is the caveat: >> >>I have only looked at the code on Brian's viewgraph, not in the Linux >>source code, so I *could* be missing some critical piece of >>information... >> >>- Sally > > > - Sally > http://www.icir.org/floyd/ > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > > -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri May 16 03:09:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15507 for ; Fri, 16 May 2003 03:09:40 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4G6b2u15796 for tsvwg-archive@odin.ietf.org; Fri, 16 May 2003 02:37:02 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4G6ZXB15762; Fri, 16 May 2003 02:35:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4G6YoB15729 for ; Fri, 16 May 2003 02:34:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15473 for ; Fri, 16 May 2003 03:06:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19GZKV-0004xS-00 for tsvwg@ietf.org; Fri, 16 May 2003 03:08:35 -0400 Received: from parmesan.cs.wisc.edu ([128.105.167.16]) by ietf-mx with esmtp (Exim 4.12) id 19GZKP-0004xM-00 for tsvwg@ietf.org; Fri, 16 May 2003 03:08:30 -0400 Received: (from poon@localhost) by parmesan.cs.wisc.edu (8.9.2/8.9.2) id CAA32688 for tsvwg@ietf.org; Fri, 16 May 2003 02:09:11 -0500 (CDT) Date: Fri, 16 May 2003 02:09:11 -0500 (CDT) From: Kacheong Poon Message-Id: <200305160709.CAA32688@parmesan.cs.wisc.edu> To: tsvwg@ietf.org Subject: Re: [Tsvwg] taking NewReno (RFC 2582) to Proposed Standard Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Included message from Randall Stewart : >---- >-----10 segments outstanding----> > and of course the reciver sends 5 acks (every >other segment)... but worse case happens and >you get > ><----ack5 ><----ack4 ><----ack3 ><----ack2 ><----ack1 > > >Now the first ack that arrives acknowledges all >of the 10 segments.. the next 4 are considered >old and dropped... > >Using ABC we would advance our cwnd from 10 >to 11. > >But if you apply the max burst you drop to 4.. real >bummer :-< > >However what happens to the network now without >some sort of burst limit? The sender is now suddenly >able to spike out 11 segments of data. And I know >this can't be a good thing :< Isn't this the whole point of maxburst? I guess many TCP implementations have this feature. What Sally pointed out in her mail was that using cwnd to limit burst was not a good idea. [ ... ] >Maybe there is someway we can control the sending without >killing the cwnd.. but then as Mark Allman as stated.. you get >two control variables and that seems like it might lead to >interaction and trouble??? Actually, using cwnd to limit burst is overloading its semantics and leads to this unwanted interaction. To me, cwnd is used to track the "macro" sending rate of TCP. The fact that TCP cannot send more than cwnd does not mean that cwnd should also be used for limiting number of segments sent per ACK, which is "micro" sending rate. >---- K. Poon. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri May 16 07:46:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20163 for ; Fri, 16 May 2003 07:46:44 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4GBE3M02001 for tsvwg-archive@odin.ietf.org; Fri, 16 May 2003 07:14:03 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GB5LB00907; Fri, 16 May 2003 07:05:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GB4iB00865 for ; Fri, 16 May 2003 07:04:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20004 for ; Fri, 16 May 2003 07:36:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19GdXr-00065l-00 for tsvwg@ietf.org; Fri, 16 May 2003 07:38:39 -0400 Received: from stewart.chicago.il.us ([66.93.186.36]) by ietf-mx with esmtp (Exim 4.12) id 19GdXl-00065U-00 for tsvwg@ietf.org; Fri, 16 May 2003 07:38:33 -0400 Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8p1/8.12.8) with ESMTP id h4GBccrf071147; Fri, 16 May 2003 06:38:39 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3EC4CDBE.30209@stewart.chicago.il.us> Date: Fri, 16 May 2003 06:38:38 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3b) Gecko/20030323 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kacheong Poon CC: tsvwg@ietf.org Subject: Re: [Tsvwg] taking NewReno (RFC 2582) to Proposed Standard References: <200305160709.CAA32688@parmesan.cs.wisc.edu> In-Reply-To: <200305160709.CAA32688@parmesan.cs.wisc.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Kacheong: I like this idea of a "macro" and "micro" control variables... I don't know if Mark will like it but it makes sense to me :-> Now, thinking on this.. there is another inter-action that one must take in to consideration.. can't remember which draft its in for TCP.. but if one does the "if you don't use the full cwnd you don't get to increase your cwnd" as we do in SCTP... this burst limit will interact with that.. aka.. My cwnd says I have room to send 10 segments (as in my earlier example).. but say a burst limit of 8 stops me until some other event happens. Now the "other event" is the ACK for the first two segments I sent... The only reason more were not sent is the burst limit not that the sender did not wish to use the full cwnd... So I think in this case the sender SHOULD be able to advance its cwnd by 1... and thus up to 11 .. which would then allow it to send out 5 more segments... So I guess the sender needs to track on every send op if the burst limit was applied.. and if so take that in to account when determing if the full cwnd was being used or intended to be used but was stopped by the burst limit... R Kacheong Poon wrote: > Included message from Randall Stewart : > > >>---- >>-----10 segments outstanding----> >> and of course the reciver sends 5 acks (every >>other segment)... but worse case happens and >>you get >> >><----ack5 >><----ack4 >><----ack3 >><----ack2 >><----ack1 >> >> >>Now the first ack that arrives acknowledges all >>of the 10 segments.. the next 4 are considered >>old and dropped... >> >>Using ABC we would advance our cwnd from 10 >>to 11. >> >>But if you apply the max burst you drop to 4.. real >>bummer :-< >> >>However what happens to the network now without >>some sort of burst limit? The sender is now suddenly >>able to spike out 11 segments of data. And I know >>this can't be a good thing :< > > > Isn't this the whole point of maxburst? I guess many > TCP implementations have this feature. What Sally > pointed out in her mail was that using cwnd to limit > burst was not a good idea. > > [ ... ] > > >>Maybe there is someway we can control the sending without >>killing the cwnd.. but then as Mark Allman as stated.. you get >>two control variables and that seems like it might lead to >>interaction and trouble??? > > > Actually, using cwnd to limit burst is overloading its > semantics and leads to this unwanted interaction. To > me, cwnd is used to track the "macro" sending rate of TCP. > The fact that TCP cannot send more than cwnd does not mean > that cwnd should also be used for limiting number of segments > sent per ACK, which is "micro" sending rate. > > >>---- > > > > K. Poon. > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > > -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri May 16 12:31:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01861 for ; Fri, 16 May 2003 12:31:10 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4GFwi323144 for tsvwg-archive@odin.ietf.org; Fri, 16 May 2003 11:58:44 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GFvBB22955; Fri, 16 May 2003 11:57:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GFtwB22861 for ; Fri, 16 May 2003 11:55:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01709 for ; Fri, 16 May 2003 12:27:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Gi5a-00012N-00 for tsvwg@ietf.org; Fri, 16 May 2003 12:29:47 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 19Gi5a-00012K-00 for tsvwg@ietf.org; Fri, 16 May 2003 12:29:46 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 089C2328CE; Fri, 16 May 2003 12:30:54 -0400 (EDT) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id 420D732893; Fri, 16 May 2003 12:30:53 -0400 (EDT) Date: Fri, 16 May 2003 12:30:53 -0400 (EDT) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: Kacheong Poon Cc: Sally Floyd , Tom Henderson , Randall Stewart , Subject: Re: [Tsvwg] taking NewReno (RFC 2582) to Proposed Standard In-Reply-To: <200305160709.CAA32688@parmesan.cs.wisc.edu> Message-ID: X-Spam-Status: No, hits=-5.0 required=6.0 tests=DEPT_RCVD,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , On Fri, 16 May 2003, Kacheong Poon wrote: > >However what happens to the network now without > >some sort of burst limit? The sender is now suddenly > >able to spike out 11 segments of data. And I know > >this can't be a good thing :< > > Isn't this the whole point of maxburst? I guess many > TCP implementations have this feature. What Sally > pointed out in her mail was that using cwnd to limit > burst was not a good idea. Yes, but NewReno TCP only uses maxburst after exiting a fast recovery. SCTP's old implementer's guide (version <= 04) did the same. The change in the SCTP implementer's guide came about after I brought up the issue that max burst should always be applied. I didn't (and still don't) see a reason why max burst should only be applied when recovering from a fast retransmit. (Randall's example scenario shows that reordering is enough to need max burst.) Mark Allman suggested, based on Congestion Window Validation, that max burst and cwnd limitations be unified as they are currently in the SCTP implementer's guide. > Actually, using cwnd to limit burst is overloading its > semantics and leads to this unwanted interaction. Yes, we thought it was a good way to overload the semantics. I see now that it is not. > To me, cwnd is used to track the "macro" sending rate of TCP. The fact > that TCP cannot send more than cwnd does not mean that cwnd should > also be used for limiting number of segments sent per ACK, which is > "micro" sending rate. Yes, agreed. I think the right thing to do is to apply max burst always. No matter what, each ack may only trigger a send of at most Max.Burst packets. ~armando 0-- --0 | Armando L. Caro Jr. | Protocol Engineering Lab | | www.cis.udel.edu/~acaro | University of Delaware | 0-- --0 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri May 16 12:50:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02646 for ; Fri, 16 May 2003 12:50:54 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4GGITk25847 for tsvwg-archive@odin.ietf.org; Fri, 16 May 2003 12:18:29 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GGHBB25783; Fri, 16 May 2003 12:17:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GGGOB25758 for ; Fri, 16 May 2003 12:16:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02507 for ; Fri, 16 May 2003 12:48:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19GiPN-0001Fx-00 for tsvwg@ietf.org; Fri, 16 May 2003 12:50:13 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 19GiPM-0001Fu-00 for tsvwg@ietf.org; Fri, 16 May 2003 12:50:12 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 66E683294C; Fri, 16 May 2003 12:51:24 -0400 (EDT) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id 87A2532944; Fri, 16 May 2003 12:51:23 -0400 (EDT) Date: Fri, 16 May 2003 12:51:23 -0400 (EDT) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: Randall Stewart Cc: Kacheong Poon , Subject: Re: [Tsvwg] taking NewReno (RFC 2582) to Proposed Standard In-Reply-To: <3EC4CDBE.30209@stewart.chicago.il.us> Message-ID: X-Spam-Status: No, hits=-5.0 required=6.0 tests=DEPT_RCVD,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_02_03,USER_AGENT_PINE version=2.43 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , On Fri, 16 May 2003, Randall Stewart wrote: > Now, thinking on this.. there is another inter-action that one > must take in to consideration.. can't remember which draft > its in for TCP.. but if one does the "if you don't use the > full cwnd you don't get to increase your cwnd" as we > do in SCTP... this burst limit will interact with that.. I don't quite follow you. Are you talking about SCTP or TCP? If SCTP, I don't think there is a problem. If TCP, I think ABC solves the problem. Maybe I am missing something... > My cwnd says I have room to send 10 segments (as in > my earlier example).. but say a burst limit of 8 stops > me until some other event happens. > > Now the "other event" is the ACK for the first two segments > I sent... > > The only reason more were not sent is the burst limit not that > the sender did not wish to use the full cwnd... I follow up to here. > So I think in this case the sender SHOULD be able to advance > its cwnd by 1... and thus up to 11 .. which would then allow > it to send out 5 more segments... Isn't the ack information for the first two segments redundant at this point? Why would the cwnd increase? > So I guess the sender needs to track on every send op if the > burst limit was applied.. and if so take that in to account when > determing if the full cwnd was being used or intended to be > used but was stopped by the burst limit... I see what you are getting at, but I don't think it is a problem with SCTP or TCP w/ ABC. The first ack (ack 5) that arrives in your reordering example acks all the outstanding data and increases the cwnd. The subsequent acks (ack 4, ack 3, ack 2, ack 1) don't increase the cwnd, but allow the sender to send more data if max burst prevented the full cwnd to be used previously. Does this make sense, or am I missing something? ~armando 0-- --0 | Armando L. Caro Jr. | Protocol Engineering Lab | | www.cis.udel.edu/~acaro | University of Delaware | 0-- --0 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri May 16 14:33:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06168 for ; Fri, 16 May 2003 14:33:04 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4GI0fP32388 for tsvwg-archive@odin.ietf.org; Fri, 16 May 2003 14:00:41 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GHwuB32301; Fri, 16 May 2003 13:58:56 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GHvrB32196 for ; Fri, 16 May 2003 13:57:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06045 for ; Fri, 16 May 2003 14:29:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19GjzX-00024B-00 for tsvwg@ietf.org; Fri, 16 May 2003 14:31:39 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx with esmtp (Exim 4.12) id 19GjzX-000248-00 for tsvwg@ietf.org; Fri, 16 May 2003 14:31:39 -0400 Received: from slb-av-01.boeing.com ([129.172.13.4]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id LAA26099; Fri, 16 May 2003 11:32:24 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.9.3p2/8.9.2/MBS-AV-02) with ESMTP id LAA02523; Fri, 16 May 2003 11:32:49 -0700 (PDT) Received: from XCH-NWBH-01.nw.nos.boeing.com (xch-nwbh-01.nw.nos.boeing.com [192.33.62.231]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h4GIWiH08344; Fri, 16 May 2003 11:32:44 -0700 (PDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-01.nw.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6662); Fri, 16 May 2003 11:32:44 -0700 Content-class: urn:content-classes:message Subject: RE: [Tsvwg] taking NewReno (RFC 2582) to Proposed Standard MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 16 May 2003 11:32:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C01483D5D@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [Tsvwg] taking NewReno (RFC 2582) to Proposed Standard Thread-Index: AcMb1OcQrWMkFxmMRG6y8yAmtfGZ8AAAOeGQ From: "Henderson, Thomas R" To: "Armando L. Caro Jr." Cc: X-OriginalArrivalTime: 16 May 2003 18:32:44.0169 (UTC) FILETIME=[8A7B3790:01C31BD9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4GHvrB32197 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Armando L. Caro Jr. [mailto:acaro@mail.eecis.udel.edu] > > Yes, agreed. I think the right thing to do is to apply max > burst always. > No matter what, each ack may only trigger a send of at most Max.Burst > packets. > Does such a recommendation, if agreed, belong in a NewReno specific document? Another issue that may or may not be NewReno specific is whether it is a good idea to recommend suppressing the sending of pure window updates intermingled with dupacks, to avoid resetting the counter to enter fast retransmit (Jeffrey Hsu mentioned this to me earlier this week). This probably is not an issue when SACK is used. Tom _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri May 16 14:38:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06302 for ; Fri, 16 May 2003 14:38:07 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4GI5iX32583 for tsvwg-archive@odin.ietf.org; Fri, 16 May 2003 14:05:44 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GI44B32515; Fri, 16 May 2003 14:04:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GI3mB32496 for ; Fri, 16 May 2003 14:03:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06262 for ; Fri, 16 May 2003 14:35:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Gk5G-00025f-00 for tsvwg@ietf.org; Fri, 16 May 2003 14:37:34 -0400 Received: from stewart.chicago.il.us ([66.93.186.36]) by ietf-mx with esmtp (Exim 4.12) id 19Gk5F-00025c-00 for tsvwg@ietf.org; Fri, 16 May 2003 14:37:33 -0400 Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8p1/8.12.8) with ESMTP id h4GIbwrf075836; Fri, 16 May 2003 13:37:59 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3EC53006.2010801@stewart.chicago.il.us> Date: Fri, 16 May 2003 13:37:58 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3b) Gecko/20030323 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Armando L. Caro Jr." CC: Kacheong Poon , tsvwg@ietf.org Subject: Re: [Tsvwg] taking NewReno (RFC 2582) to Proposed Standard References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Armando; I see from your response my first example was a bad one to use for this.. My point is there IS some cases where you will have a bad interaction... Heres a different example: ------data-1--------> ------data-2---------> -----data-3----------> -----data-4---------> -----data-5---------> -----data-6---------> -----data-7---------> -----data-8---------> ... -----data-10------> (peer is acking every 5th packet.. as Sally points out not all implementations ack every other...) XlostX<---------ack-5------- <---------ack-10---- Cwnd = 11. (add one with ABC) ------------data-11----> ------------data-12----> ------------data-13----> -----------data-14-----> 200ms timer expires <--------ack-14------- So here we are... a ack arrives but we are not using the full cwnd (11) only 4 outstanding... so ABC or SCTP says you are not using the whole cwnd.. no advance and you get to send maxburst more, wait for the 200ms timer.. and are now stuck. I am sure there are other examples one can come up with.. but that is just a quick one... R Armando L. Caro Jr. wrote: > On Fri, 16 May 2003, Randall Stewart wrote: > > >>Now, thinking on this.. there is another inter-action that one >>must take in to consideration.. can't remember which draft >>its in for TCP.. but if one does the "if you don't use the >>full cwnd you don't get to increase your cwnd" as we >>do in SCTP... this burst limit will interact with that.. > > > I don't quite follow you. Are you talking about SCTP or TCP? If SCTP, I > don't think there is a problem. If TCP, I think ABC solves the problem. > Maybe I am missing something... > > >>My cwnd says I have room to send 10 segments (as in >>my earlier example).. but say a burst limit of 8 stops >>me until some other event happens. >> >>Now the "other event" is the ACK for the first two segments >>I sent... >> >>The only reason more were not sent is the burst limit not that >>the sender did not wish to use the full cwnd... > > > I follow up to here. > > >>So I think in this case the sender SHOULD be able to advance >>its cwnd by 1... and thus up to 11 .. which would then allow >>it to send out 5 more segments... > > > Isn't the ack information for the first two segments redundant at this > point? Why would the cwnd increase? > > >>So I guess the sender needs to track on every send op if the >>burst limit was applied.. and if so take that in to account when >>determing if the full cwnd was being used or intended to be >>used but was stopped by the burst limit... > > > I see what you are getting at, but I don't think it is a problem with SCTP > or TCP w/ ABC. The first ack (ack 5) that arrives in your reordering > example acks all the outstanding data and increases the cwnd. The > subsequent acks (ack 4, ack 3, ack 2, ack 1) don't increase the cwnd, but > allow the sender to send more data if max burst prevented the full cwnd to > be used previously. > > Does this make sense, or am I missing something? > > ~armando > > 0-- --0 > | Armando L. Caro Jr. | Protocol Engineering Lab | > | www.cis.udel.edu/~acaro | University of Delaware | > 0-- --0 > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > > -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri May 16 14:47:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06486 for ; Fri, 16 May 2003 14:47:55 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4GIFX801442 for tsvwg-archive@odin.ietf.org; Fri, 16 May 2003 14:15:33 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GIE5B01368; Fri, 16 May 2003 14:14:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GIDAB01335 for ; Fri, 16 May 2003 14:13:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06416 for ; Fri, 16 May 2003 14:45:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19GkEK-00028U-00 for tsvwg@ietf.org; Fri, 16 May 2003 14:46:56 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by ietf-mx with esmtp (Exim 4.12) id 19GkEJ-000288-00 for tsvwg@ietf.org; Fri, 16 May 2003 14:46:55 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h4GIlTWj006521; Fri, 16 May 2003 11:47:32 -0700 (PDT) Received: from cisco.com (mbashyam-u10.cisco.com [10.34.36.39]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AHE51352; Fri, 16 May 2003 11:40:40 -0700 (PDT) Message-ID: <3EC5323C.1F5A858A@cisco.com> Date: Fri, 16 May 2003 11:47:24 -0700 From: Murali Bashyam Organization: Cisco Systems Inc X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Henderson, Thomas R" CC: "Armando L. Caro Jr." , tsvwg@ietf.org Subject: Re: [Tsvwg] taking NewReno (RFC 2582) to Proposed Standard References: <6938661A6EDA8A4EA8D1419BCE46F24C01483D5D@xch-nw-27.nw.nos.boeing.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit "Henderson, Thomas R" wrote: > > -----Original Message----- > > From: Armando L. Caro Jr. [mailto:acaro@mail.eecis.udel.edu] > > > > Yes, agreed. I think the right thing to do is to apply max > > burst always. > > No matter what, each ack may only trigger a send of at most Max.Burst > > packets. > > > > Does such a recommendation, if agreed, belong in a NewReno specific document? > > Another issue that may or may not be NewReno specific is whether it is a good idea to recommend suppressing the sending of pure window updates intermingled with dupacks, to avoid resetting the counter to enter fast retransmit (Jeffrey Hsu mentioned this to me earlier this week). This probably is not an issue when SACK is used. During recent testing with NewReno, we had observed this too, and it's a good idea to consider suppressing pure window updates, to reduce the recovery time. With regard to burstiness introduced by the fast recovery algorithm, we observed an interesting behaviour and i thought it might be relevant to this discussion. Sometimes we had noticed that the sender increments cwnd in response to a duplicate ACK by a MSS, and then does not use this cwnd because there is no new application data available to send, and after several duplicate ACKs (still remaining in fast recovery phase), the application queues more data, and the sender now uses the cwnd all at once to transmit a long burst of packets, sometimes upto 10 or 11 packets back to back. I agree this is not NewReno specific, i think the scenario is likely to happen with Reno too, but the solution to avoid this burst is to use the maxburst parameter, i guess? Murali > > > Tom > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri May 16 15:05:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07353 for ; Fri, 16 May 2003 15:05:36 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4GIXCR02299 for tsvwg-archive@odin.ietf.org; Fri, 16 May 2003 14:33:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GIU9B02196; Fri, 16 May 2003 14:30:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GITIB02157 for ; Fri, 16 May 2003 14:29:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07048 for ; Fri, 16 May 2003 15:01:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19GkTv-0002Gj-00 for tsvwg@ietf.org; Fri, 16 May 2003 15:03:03 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 19GkTv-0002Gg-00 for tsvwg@ietf.org; Fri, 16 May 2003 15:03:03 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id A7111329B8; Fri, 16 May 2003 15:04:11 -0400 (EDT) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id D65FA32951; Fri, 16 May 2003 15:04:10 -0400 (EDT) Date: Fri, 16 May 2003 15:04:10 -0400 (EDT) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: "Henderson, Thomas R" Cc: Subject: RE: [Tsvwg] taking NewReno (RFC 2582) to Proposed Standard In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C01483D5D@xch-nw-27.nw.nos.boeing.com> Message-ID: X-Spam-Status: No, hits=-4.2 required=6.0 tests=DEPT_RCVD,EMAIL_ATTRIBUTION,IN_REP_TO,SPAM_PHRASE_00_01, USER_AGENT_PINE version=2.43 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , On Fri, 16 May 2003, Henderson, Thomas R wrote: > Does such a recommendation, if agreed, belong in a NewReno specific document? I am not sure. Maybe it should be in a protocol/TCP-variant independent document. What do others think? ~armando 0-- --0 | Armando L. Caro Jr. | Protocol Engineering Lab | | www.cis.udel.edu/~acaro | University of Delaware | 0-- --0 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri May 16 15:35:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08978 for ; Fri, 16 May 2003 15:35:27 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4GJ34O04590 for tsvwg-archive@odin.ietf.org; Fri, 16 May 2003 15:03:04 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GJ1gB04440; Fri, 16 May 2003 15:01:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GIruB04107 for ; Fri, 16 May 2003 14:53:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08738 for ; Fri, 16 May 2003 15:25:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Gkrl-0002Of-00 for tsvwg@ietf.org; Fri, 16 May 2003 15:27:41 -0400 Received: from stewart.chicago.il.us ([66.93.186.36]) by ietf-mx with esmtp (Exim 4.12) id 19Gkrk-0002OX-00 for tsvwg@ietf.org; Fri, 16 May 2003 15:27:40 -0400 Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8p1/8.12.8) with ESMTP id h4GJSCrf076124; Fri, 16 May 2003 14:28:13 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3EC53BCC.7000708@stewart.chicago.il.us> Date: Fri, 16 May 2003 14:28:12 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3b) Gecko/20030323 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Armando L. Caro Jr." CC: Kacheong Poon , tsvwg@ietf.org Subject: Re: [Tsvwg] taking NewReno (RFC 2582) to Proposed Standard References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Armando L. Caro Jr. wrote: > Randall, > > Ok, I see the problem now, but I am still trying to decide whether that is > something we should be concerned about. Protection against this type of > interaction seems tricky to me, and I don't know how common it is for > receivers to ack more than 2 packets. Maybe their are "smart" devices > which collapse acks so that the sender sees an ack for more than two > packets?? I think there are possibly more ways you can get this situation than just if the peer is acking every 4th packet... even in the every other packet catagory I think you can hit this... > > I guess what I am getting at is... Unless their is straight forward way to > avoid this problem, I don't _think_ its worth addressing it. Is it? > I think there is a straight forward solution that is quite simple... You set a flag when maxburst is imposed and clear it if it is not in your sending routine. Then when SACKs arrive.. speaking for SCTP (same would work for TCP ABC I think) 1) Make sure the cum ack as moved forward .. if not no advance 2) See if the full cwnd was being used OR max burst was in effect at the last send. If either of these are true we ARE allowed to do the cwnd advancement. Its a simple flag/boolean and checking it along with are you using the full cwnd... R > ~armando > > 0-- --0 > | Armando L. Caro Jr. | Protocol Engineering Lab | > | www.cis.udel.edu/~acaro | University of Delaware | > 0-- --0 > > On Fri, 16 May 2003, Randall Stewart wrote: > > >>Armando; >> >>I see from your response my first example was a >>bad one to use for this.. My point is there IS some cases >>where you will have a bad interaction... >> >>Heres a different example: >> >>------data-1--------> >>------data-2---------> >>-----data-3----------> >>-----data-4---------> >>-----data-5---------> >>-----data-6---------> >>-----data-7---------> >>-----data-8---------> >>... >>-----data-10------> >> >>(peer is acking every 5th packet.. as Sally points out not >> all implementations ack every other...) >> >>XlostX<---------ack-5------- >><---------ack-10---- >>Cwnd = 11. (add one with ABC) >> >>------------data-11----> >>------------data-12----> >>------------data-13----> >>-----------data-14-----> >> >> >> 200ms timer expires >> <--------ack-14------- >> >>So here we are... a ack arrives but we are not using >>the full cwnd (11) only 4 outstanding... so ABC or SCTP >>says you are not using the whole cwnd.. no advance >>and you get to send maxburst more, wait for the >>200ms timer.. and are now stuck. >> >>I am sure there are other examples one can come up with.. but that >>is just a quick one... >> >>R > > > > -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri May 16 15:37:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09069 for ; Fri, 16 May 2003 15:37:26 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4GJ53u04745 for tsvwg-archive@odin.ietf.org; Fri, 16 May 2003 15:05:03 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GJ33B04588; Fri, 16 May 2003 15:03:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GJ2lB04556 for ; Fri, 16 May 2003 15:02:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08948 for ; Fri, 16 May 2003 15:34:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Gl0K-0002Ru-00 for tsvwg@ietf.org; Fri, 16 May 2003 15:36:32 -0400 Received: from stewart.chicago.il.us ([66.93.186.36]) by ietf-mx with esmtp (Exim 4.12) id 19Gl0J-0002Rm-00 for tsvwg@ietf.org; Fri, 16 May 2003 15:36:31 -0400 Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8p1/8.12.8) with ESMTP id h4GJb5rf076204; Fri, 16 May 2003 14:37:05 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3EC53DE1.8090205@stewart.chicago.il.us> Date: Fri, 16 May 2003 14:37:05 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3b) Gecko/20030323 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randall Stewart CC: TSV WG list Subject: Re: [Tsvwg] Update to the changes for PRSCTP References: <3EC2468D.8030405@stewart.chicago.il.us> In-Reply-To: <3EC2468D.8030405@stewart.chicago.il.us> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Randall Stewart wrote: > Hi all: > > Once again I have updated all comments and changes to > the PR-SCTP draft. > > Please have a look at the html at > > http://www.sctp.org > > under internet drafts you will find a link to the diff > document.. > > Have a look and please send comments... I intend to > submit this by Friday.. > > Thanks > > R I have submitted the -04 draft and once again did a update to the comparision found at the above web site. One additional change was made in regard to old Fwd-tsn's we used to silently discard them.. now we treat them the same as you would duplicate data... send a sack.. The draft should be out soon.. but the changes can be found above in HTML form :> R -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri May 16 15:38:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09105 for ; Fri, 16 May 2003 15:38:31 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4GJ67i04800 for tsvwg-archive@odin.ietf.org; Fri, 16 May 2003 15:06:07 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GJ1bB04392; Fri, 16 May 2003 15:01:37 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GIlNB03881 for ; Fri, 16 May 2003 14:47:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08597 for ; Fri, 16 May 2003 15:19:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19GklQ-0002Mr-00 for tsvwg@ietf.org; Fri, 16 May 2003 15:21:08 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 19GklQ-0002Mo-00 for tsvwg@ietf.org; Fri, 16 May 2003 15:21:08 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 6A7DE3297D; Fri, 16 May 2003 15:22:20 -0400 (EDT) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id A63D632936; Fri, 16 May 2003 15:22:19 -0400 (EDT) Date: Fri, 16 May 2003 15:22:19 -0400 (EDT) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: Randall Stewart Cc: Kacheong Poon , Subject: Re: [Tsvwg] taking NewReno (RFC 2582) to Proposed Standard In-Reply-To: <3EC53006.2010801@stewart.chicago.il.us> Message-ID: X-Spam-Status: No, hits=-4.7 required=6.0 tests=DEPT_RCVD,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_03_05,USER_AGENT_PINE version=2.43 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Randall, Ok, I see the problem now, but I am still trying to decide whether that is something we should be concerned about. Protection against this type of interaction seems tricky to me, and I don't know how common it is for receivers to ack more than 2 packets. Maybe their are "smart" devices which collapse acks so that the sender sees an ack for more than two packets?? I guess what I am getting at is... Unless their is straight forward way to avoid this problem, I don't _think_ its worth addressing it. Is it? ~armando 0-- --0 | Armando L. Caro Jr. | Protocol Engineering Lab | | www.cis.udel.edu/~acaro | University of Delaware | 0-- --0 On Fri, 16 May 2003, Randall Stewart wrote: > Armando; > > I see from your response my first example was a > bad one to use for this.. My point is there IS some cases > where you will have a bad interaction... > > Heres a different example: > > ------data-1--------> > ------data-2---------> > -----data-3----------> > -----data-4---------> > -----data-5---------> > -----data-6---------> > -----data-7---------> > -----data-8---------> > ... > -----data-10------> > > (peer is acking every 5th packet.. as Sally points out not > all implementations ack every other...) > > XlostX<---------ack-5------- > <---------ack-10---- > Cwnd = 11. (add one with ABC) > > ------------data-11----> > ------------data-12----> > ------------data-13----> > -----------data-14-----> > > > 200ms timer expires > <--------ack-14------- > > So here we are... a ack arrives but we are not using > the full cwnd (11) only 4 outstanding... so ABC or SCTP > says you are not using the whole cwnd.. no advance > and you get to send maxburst more, wait for the > 200ms timer.. and are now stuck. > > I am sure there are other examples one can come up with.. but that > is just a quick one... > > R _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon May 19 00:10:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24780 for ; Mon, 19 May 2003 00:10:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4J3d9s30766 for tsvwg-archive@odin.ietf.org; Sun, 18 May 2003 23:39:09 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4J3bOB30426; Sun, 18 May 2003 23:37:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4J3Z8B29822 for ; Sun, 18 May 2003 23:35:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24746 for ; Mon, 19 May 2003 00:05:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Hbw5-000731-00 for tsvwg@ietf.org; Mon, 19 May 2003 00:07:41 -0400 Received: from d14-69-204-117.clv.wideopenwest.com ([69.14.117.204] helo=lawyers.ir.bbn.com) by ietf-mx with esmtp (Exim 4.12) id 19Hbw4-00072y-00 for tsvwg@ietf.org; Mon, 19 May 2003 00:07:40 -0400 Received: by lawyers.ir.bbn.com (Postfix, from userid 9076) id 7A3406B17A; Mon, 19 May 2003 00:08:13 -0400 (EDT) To: Randall Stewart Cc: "Armando L. Caro Jr." , "Sally Floyd" , Kacheong Poon , tsvwg@ietf.org From: Mark Allman Reply-To: mallman@grc.nasa.gov Subject: Re: [Tsvwg] taking NewReno (RFC 2582) to Proposed Standard In-Reply-To: <3EC53BCC.7000708@stewart.chicago.il.us> Organization: BBN Technologies/NASA GRC Song-of-the-Day: Wishlist Date: Mon, 19 May 2003 00:08:12 -0400 Message-Id: <20030519040813.7A3406B17A@lawyers.ir.bbn.com> Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Folks- I have a few comments on this bursting discussion. The caveat is that these are all pretty general thoughts. I have not read the recent newreno draft (yet) and so I do not know what it says exactly. But, I have some thoughts on the two anti-bursting schemes thrown out already and would then like to throw out a third variant. My thoughts: * There are some situations when TCP (SCTP) can burst a good amount of segments at line rate. In some situations this is OK and everything works itself out. In some situations this is not OK and the burst causes drops (and the resulting loss recovery and cwnd reduction). So, bursting is sort of a mixed bag. * Do we need some sort of general burst limiting mechanism? Beats me. * But, for argument's sake lets say that we're going to go down that path. Two scheme have been thrown out: (1) maxburst controller count = 0 while ((outstanding_data < cwnd) && (count < maxburst)) send_segment () outstanding_data++ count++ (2) reseting cwnd if ((outstanding_data + maxburst) < cwnd) cwnd = outstanding_data + maxburst while (outstanding_data < cwnd) send_segment () outstanding_data++ * To my way of looking at things, scheme (1) uses two controls for how much data can be sent into the network. That is, we can either be limited by cwnd or we can be limited by maxburst. And, since there are two controls there are interactions between them that must be taken into account -- in specs and code. And, there are things that are currently speced that will break. That is, TCP can be running in a state where there is less than cwnd on the network because it is limited by maxburst instead of cwnd and the specs/code do not envision the case and therefore cannot be exepected to do something intelligent. An example of where this breaks things: The limited transmit spec says that on dup acks TCP can inject at most cwnd+(2*MSS) of new data into the network. The hope was that this means that we can send data on the first two dup acks. If maxburst has limited the amount of outstanding data to something less than cwnd then limited transmit now allows the sending of more than two new segments on dup ACKs. That might be OK. But, I think that is clearly at odds with the spirit of RFC 3042. I think there are likely quite a number of examples of unintended interactions/consequences. But, that can be fixed... we can set a flag, add some conditionals, some temporary variables, write some new text and plug up these things right up... * On the other hand, scheme (2) has only a single controller. We are always limited by cwnd -- and, maxburst is just an input to this controller. On the surface, the above snippets of code may look the same, but they are not. If you take the limited transmit case again... LT has no problem under scheme (2) because the cwnd is now tracking the amount of outstanding data. All of our code and our specs this to be the way things are. So, this works nicely. However, Sally has noted some nasty examples whereby scheme (2) pulls down the cwnd when we'd really like it to not do that. I buy those and am sympathetic. * So, next we look at what the long-term differences in the above bits of code. Scheme (1) limits how much can be sent to maxburst packets at a time. But, cwnd is retained. So, conceivably we could "catch up" to cwnd over time. That is, we burst less at first but then a bit more for a few ACKs until we end up having "outstanding_data == cwnd" again. Scheme (2) on the other hand, sacrifices cwnd space immediately. TCP must then build it back up over time per normal congestion avoidance. My guess is that you could show that scheme (1) always gets back to outstanding_data == orig_cwnd faster than scheme (2) (or, maybe equally fast in some cases). * Now let me take a minute and say that (a) I do not care for the downsides of scheme (2) that Sally illustrated and (b) I think that scheme (1) is equally bogus because it adds a second control for the amount of outstanding data -- and no end of headaches will come of it. Also, I do not buy that because TCP sends "micro" and "macro" bursts that we should have two controllers for these sending patterns. It makes no sense to me since in the end they control the same thing: the amount of data that can be dumped into the network. * So, the question I am left puzzling over is: can we combine schemes (1) and (2) in a sensible way to avoid the downsides that Sally has shown while also avoiding a second control on outstanding data? * One more observation: If maxburst is 4, we use scheme (1), we use delayed ACKs, cwnd = outstanding_data = 10 segments and we get an ACK that covers 10 previously unACKed segments (because of dropped ACKs) the events will look like this: get ACK for 10 segments; send 4 segments (outstanding = 4; cwnd = 10) get ACK for 2 segments; send 4 segments (outstanding = 6; cwnd = 10) get ACK for 2 segments; send 4 segments (outstanding = 8; cwnd = 10) get ACK for 2 segments; send 4 segments (outstanding = 10; cwnd = 10) get ACK for 2 segments; send 2 segments (outstanding = 10; cwnd = 10) I.e., it's slow start. * So, what if we introduce a scheme (3), which is really just a riff of scheme (2): if ((outstanding_data + maxburst) < cwnd) if (ssthresh < cwnd) ssthresh = cwnd cwnd = outstanding_data + maxburst while (outstanding_data < cwnd) send_segment () outstanding_data++ In other words, we clamp cwnd to limit the burst, but we also set ssthresh in such a way that we can slow start to climb out of the cwnd reduction. It is late, but I think this gives us the good points of (1) and (2) -- that is, one controller with the same basic pattern of sending given by scheme (1). Thoughts? [Also, with appologies to Joe Touch & Amy Hughes --- who probably had all this figured out long ago (but, their exact ideas have fallen out of my head.] allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon May 19 09:18:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20120 for ; Mon, 19 May 2003 09:18:35 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4JClXa15332 for tsvwg-archive@odin.ietf.org; Mon, 19 May 2003 08:47:33 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JCgrB15061; Mon, 19 May 2003 08:42:53 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JCfTB14997 for ; Mon, 19 May 2003 08:41:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19984; Mon, 19 May 2003 09:12:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19HkSb-0003IO-00; Mon, 19 May 2003 09:13:50 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by ietf-mx with esmtp (Exim 4.12) id 19HkSW-0003I2-00; Mon, 19 May 2003 09:13:44 -0400 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h4JCibeS021633; Mon, 19 May 2003 05:44:38 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AHJ78592; Mon, 19 May 2003 05:44:36 -0700 (PDT) Message-ID: <3EC8D1B3.7000708@cisco.com> Date: Mon, 19 May 2003 07:44:35 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3b) Gecko/20030323 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mrajpal@hss.hns.com CC: tsvwg@ietf.org, sctp-impl@external.cisco.com References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Tsvwg] Re: clarification required for sctp socket draft 06 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit sac_info is the correct name.. the sac_data must be left over from a old previous version.. I have fixed it in the xml so this will be corrected in -07 R mrajpal@hss.hns.com wrote: > > > >hi, > >In section 5.3.1.1 of draft-ietf-tsvwg-sctpsocket-06.txt,, the structure >definiition is > >struct sctp_assoc_change { > uint16_t sac_type; > uint16_t sac_flags; > uint32_t sac_length; > uint16_t sac_state; > uint16_t sac_error; > uint16_t sac_outbound_streams; > uint16_t sac_inbound_streams; > sctp_assoc_t sac_assoc_id; > uint8_t sac_info[0]; > }; > >The last member sac_info is mentioned as sac_data in the description given >in the same section. > >Please clarify what should be the member called, sac_info or sac_data. > > >regards >manish > >Hughes Software Systems >http://www.hssworld.com > >"DISCLAIMER: This message is proprietary to Hughes Software Systems Limited >(HSS) and is intended solely for the use of the individual to whom it is >addressed. It may contain privileged or confidential information and >should not be circulated or used for any purpose other than for what it is >intended. If you have received this message in error, please notify the >originator immediately. If you are not the intended recipient, you are >notified that you are strictly prohibited from using, copying, altering, or >disclosing the contents of this message. HSS accepts no responsibility for >loss or damage arising from the use of the information transmitted by this >email including damage from virus." > > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon May 19 09:42:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20687 for ; Mon, 19 May 2003 09:42:59 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4JDBw317862 for tsvwg-archive@odin.ietf.org; Mon, 19 May 2003 09:11:58 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JD6JB16527; Mon, 19 May 2003 09:06:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JD0rB16230 for ; Mon, 19 May 2003 09:00:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20383 for ; Mon, 19 May 2003 09:31:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Hkl8-0003Po-00 for tsvwg@ietf.org; Mon, 19 May 2003 09:32:59 -0400 Received: from seraph3.grc.nasa.gov ([128.156.10.12]) by ietf-mx with esmtp (Exim 4.12) id 19Hkl3-0003PB-00 for tsvwg@ietf.org; Mon, 19 May 2003 09:32:53 -0400 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 71BF96BA62 for ; Mon, 19 May 2003 09:33:06 -0400 (EDT) Received: from guns.lerc.nasa.gov (guns.grc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h4JDX4uW004063; Mon, 19 May 2003 09:33:04 -0400 (EDT) Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id JAA97800; Mon, 19 May 2003 09:33:04 -0400 (EDT) Message-Id: <200305191333.JAA97800@guns.lerc.nasa.gov> To: Randall Stewart , "Armando L. Caro Jr." , "Sally Floyd" , Kacheong Poon , tsvwg@ietf.org From: Mark Allman Reply-To: mallman@grc.nasa.gov Subject: Re: [Tsvwg] taking NewReno (RFC 2582) to Proposed Standard In-Reply-To: <20030519040813.7A3406B17A@lawyers.ir.bbn.com> Organization: BBN Technologies/NASA GRC Song-of-the-Day: Lift Me Up Date: Mon, 19 May 2003 09:33:04 -0400 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Randall noted that my code was a bit confusing because it lacks brackets. I have been programming python lately and so the independation just Made Sense to me. In any case, just for clarity, this code: > * So, what if we introduce a scheme (3), which is really just a > riff of scheme (2): > > if ((outstanding_data + maxburst) < cwnd) > if (ssthresh < cwnd) > ssthresh = cwnd > cwnd = outstanding_data + maxburst > while (outstanding_data < cwnd) > send_segment () > outstanding_data++ was meant to be: if ((outstanding_data + maxburst) < cwnd) { if (ssthresh < cwnd) { ssthresh = cwnd; } cwnd = outstanding_data + maxburst } while (outstanding_data < cwnd) { send_segment () outstanding_data++ } If it caused you confusion, sorry! allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon May 19 11:22:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24363 for ; Mon, 19 May 2003 11:22:52 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4JEppc24935 for tsvwg-archive@odin.ietf.org; Mon, 19 May 2003 10:51:51 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JEnNB24863; Mon, 19 May 2003 10:49:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JEmfB24826 for ; Mon, 19 May 2003 10:48:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24235 for ; Mon, 19 May 2003 11:18:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19HmRR-00045t-00 for tsvwg@ietf.org; Mon, 19 May 2003 11:20:45 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx with esmtp (Exim 4.12) id 19HmRL-00045n-00 for tsvwg@ietf.org; Mon, 19 May 2003 11:20:40 -0400 Received: from blv-av-02.boeing.com ([192.42.227.217]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id IAA11472; Mon, 19 May 2003 08:21:28 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-02.boeing.com (8.9.3p2/8.9.2/MBS-AV-02) with ESMTP id IAA23862; Mon, 19 May 2003 08:21:27 -0700 (PDT) Received: from XCH-NWBH-01.nw.nos.boeing.com (xch-nwbh-01.nw.nos.boeing.com [192.33.62.231]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h4JFLQH11731; Mon, 19 May 2003 08:21:26 -0700 (PDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-01.nw.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6662); Mon, 19 May 2003 08:20:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Tsvwg] taking NewReno (RFC 2582) to Proposed Standard Date: Mon, 19 May 2003 08:20:08 -0700 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C01483D72@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [Tsvwg] taking NewReno (RFC 2582) to Proposed Standard Thread-Index: AcMdvZhw0xM8zXqnQ9G7br3cL7uG8AAVuXgw From: "Henderson, Thomas R" To: , "Randall Stewart" Cc: "Armando L. Caro Jr." , "Sally Floyd" , "Kacheong Poon" , X-OriginalArrivalTime: 19 May 2003 15:20:54.0786 (UTC) FILETIME=[3D97FE20:01C31E1A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4JEmvB24833 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > Mark Allman wrote: > > * Do we need some sort of general burst limiting mechanism? > > Beats me. I have observed cases leaving Reno-ish fast recovery where the resulting FlightSize << ssthresh, so there are large bursts upon leaving Fast Recovery. Two causes that I have observed are: i) dupacks lost. ii) slow receiver that fails to send pure window updates, thereby causing dupacks (with slightly different windows) to be interpreted by the sender as window updates, and not triggering a transmission off the top of the window. > And, since there are two controls there are interactions between > them that must be taken into account -- in specs and code. And, I'd rather have that interaction than undesired coupling due to overloaded variables. > there are things that are currently speced that will break. > That is, TCP can be running in a state where there is less than > cwnd on the network because it is limited by maxburst instead of > cwnd and the specs/code do not envision the case and therefore > cannot be exepected to do something intelligent. > > An example of where this breaks things: The limited transmit > spec says that on dup acks TCP can inject at most cwnd+(2*MSS) > of new data into the network. The hope was that this means that > we can send data on the first two dup acks. If maxburst has > limited the amount of outstanding data to something less than > cwnd then limited transmit now allows the sending of more than > two new segments on dup ACKs. That might be OK. But, I think > that is clearly at odds with the spirit of RFC 3042. I think > there are likely quite a number of examples of unintended > interactions/consequences. If maxburst always applies, and is set to a not-too-small value, I don't see the problem. I agree that if maxburst only applies to leaving fast recovery, that having FlightSize << cwnd can cause problems later on. But I also have the same concerns as Sally about cutting down cwnd as a means to limit bursts. So the main issue seems to me to be, if maxburst is considered a good thing to recommend, shouldn't it be more broadly applicable than the case of leaving fast recovery, and therefore discussed in a document like RFC 2581? > * One more observation: If maxburst is 4, we use scheme (1), we > use delayed ACKs, cwnd = outstanding_data = 10 segments and we > get an ACK that covers 10 previously unACKed segments (because > of dropped ACKs) the events will look like this: > > get ACK for 10 segments; send 4 segments > (outstanding = 4; cwnd = 10) > get ACK for 2 segments; send 4 segments > (outstanding = 6; cwnd = 10) > get ACK for 2 segments; send 4 segments > (outstanding = 8; cwnd = 10) > get ACK for 2 segments; send 4 segments > (outstanding = 10; cwnd = 10) > get ACK for 2 segments; send 2 segments > (outstanding = 10; cwnd = 10) > > I.e., it's slow start. > I disagree-- it is smoothed transmission of "credits" you have already built up in the network. I thought that the observation about micro and macro control summed it up nicely. Tom _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon May 19 11:34:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24616 for ; Mon, 19 May 2003 11:34:26 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4JF3P425526 for tsvwg-archive@odin.ietf.org; Mon, 19 May 2003 11:03:25 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JF27B25494; Mon, 19 May 2003 11:02:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JF1PB25466 for ; Mon, 19 May 2003 11:01:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24559 for ; Mon, 19 May 2003 11:31:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Hmdk-00049e-00 for tsvwg@ietf.org; Mon, 19 May 2003 11:33:28 -0400 Received: from seraph3.grc.nasa.gov ([128.156.10.12]) by ietf-mx with esmtp (Exim 4.12) id 19Hmdf-00049G-00 for tsvwg@ietf.org; Mon, 19 May 2003 11:33:23 -0400 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 34F5F6BA66 for ; Mon, 19 May 2003 11:33:20 -0400 (EDT) Received: from guns.lerc.nasa.gov (guns.grc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h4JFXIuW007836; Mon, 19 May 2003 11:33:18 -0400 (EDT) Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id LAA99184; Mon, 19 May 2003 11:33:18 -0400 (EDT) Message-Id: <200305191533.LAA99184@guns.lerc.nasa.gov> To: "Henderson, Thomas R" From: Mark Allman Reply-To: mallman@grc.nasa.gov Cc: "Randall Stewart" , "Armando L. Caro Jr." , "Sally Floyd" , "Kacheong Poon" , tsvwg@ietf.org Subject: Re: [Tsvwg] taking NewReno (RFC 2582) to Proposed Standard In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C01483D72@xch-nw-27.nw.nos.boeing.com> Organization: BBN Technologies/NASA GRC Song-of-the-Day: Lift Me Up Date: Mon, 19 May 2003 11:33:18 -0400 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , > > And, since there are two controls there are interactions > > between them that must be taken into account -- in specs and > > code. And, > > I'd rather have that interaction than undesired coupling due to > overloaded variables. I guess we just have different ways to look at things... I don't see this as overloading cwnd -- which it seems to me is used to control the amount of data sent into the network. > If maxburst always applies, and is set to a not-too-small value,=20 > I don't see the problem. I agree that if maxburst only applies to=20 > leaving fast recovery, that having FlightSize << cwnd can cause=20 > problems later on. But I also have the same concerns as Sally about > cutting down cwnd as a means to limit bursts. What if we allow slow start after doing the cut? > So the main issue seems to me to be, if maxburst is considered a > good thing to recommend, shouldn't it be more broadly applicable > than the case of leaving fast recovery, and therefore discussed in > a=20 document like RFC 2581? I agree. I think this is beyond the revision of 2582. > > * One more observation: If maxburst is 4, we use scheme (1), we > > use delayed ACKs, cwnd =3D outstanding_data =3D 10 segments and we > > get an ACK that covers 10 previously unACKed segments (because > > of dropped ACKs) the events will look like this: > >=20 > > get ACK for 10 segments; send 4 segments > > (outstanding =3D 4; cwnd =3D 10) > > get ACK for 2 segments; send 4 segments > > (outstanding =3D 6; cwnd =3D 10) > > get ACK for 2 segments; send 4 segments > > (outstanding =3D 8; cwnd =3D 10) > > get ACK for 2 segments; send 4 segments > > (outstanding =3D 10; cwnd =3D 10) > > get ACK for 2 segments; send 2 segments > > (outstanding =3D 10; cwnd =3D 10) > > > > I.e., it's slow start. > > I disagree-- it is smoothed transmission of "credits" you have > already built up in the network. Yeah, I can understand that. My point was that this smooth transmission of credits follows the exact (in my example) pattern of slow start. (And, in a more general context the sending pattern of maxburst is probably better stated as "approximating slow start".) allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon May 19 12:00:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25259 for ; Mon, 19 May 2003 12:00:29 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4JFTTl27429 for tsvwg-archive@odin.ietf.org; Mon, 19 May 2003 11:29:29 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JFRiB27384; Mon, 19 May 2003 11:27:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JFQWB27326 for ; Mon, 19 May 2003 11:26:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25130 for ; Mon, 19 May 2003 11:56:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Hn23-0004J9-00 for tsvwg@ietf.org; Mon, 19 May 2003 11:58:35 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx with esmtp (Exim 4.12) id 19Hn1x-0004J4-00 for tsvwg@ietf.org; Mon, 19 May 2003 11:58:29 -0400 Received: from slb-av-02.boeing.com ([129.172.13.7]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id IAA22993; Mon, 19 May 2003 08:58:49 -0700 (PDT) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-02.boeing.com (8.9.3p2/8.9.2/MBS-AV-02) with ESMTP id IAA17604; Mon, 19 May 2003 08:59:14 -0700 (PDT) Received: from XCH-NWBH-01.nw.nos.boeing.com (xch-nwbh-01.nw.nos.boeing.com [192.33.62.231]) by slb-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h4JFxCn10873; Mon, 19 May 2003 08:59:13 -0700 (PDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-01.nw.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6662); Mon, 19 May 2003 08:59:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Tsvwg] taking NewReno (RFC 2582) to Proposed Standard Date: Mon, 19 May 2003 08:59:09 -0700 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C01483D74@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [Tsvwg] taking NewReno (RFC 2582) to Proposed Standard Thread-Index: AcMeG/xI+MUPL9oVQqm9WNgcAgli9gAAIt2g From: "Henderson, Thomas R" To: Cc: "Randall Stewart" , "Armando L. Caro Jr." , "Sally Floyd" , "Kacheong Poon" , X-OriginalArrivalTime: 19 May 2003 15:59:09.0715 (UTC) FILETIME=[957A5E30:01C31E1F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4JFQlB27331 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > > If maxburst always applies, and is set to a not-too-small value, > > I don't see the problem. I agree that if maxburst only > > applies to > > leaving fast recovery, that having FlightSize << cwnd can cause > > problems later on. But I also have the same concerns as Sally about > > cutting down cwnd as a means to limit bursts. > > What if we allow slow start after doing the cut? > My initial feeling is that it would cause a net reduction in the overall sending rate, but how significant, I'm not sure: i) with maxburst, while you are limiting bursts, you are still building cwnd further during that period, while with your slow start proposal, you spend a few RTTs just getting back to the cwnd you had, ii) by reducing cwnd, you are more vulnerable to additional reductions if a loss event occurs while you are trying to build back up. Tom _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon May 19 12:50:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26882 for ; Mon, 19 May 2003 12:50:38 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4JGJdC31680 for tsvwg-archive@odin.ietf.org; Mon, 19 May 2003 12:19:39 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JGIFB31453; Mon, 19 May 2003 12:18:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JGGaB31255 for ; Mon, 19 May 2003 12:16:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26762 for ; Mon, 19 May 2003 12:46:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19HnoU-0004pi-00 for tsvwg@ietf.org; Mon, 19 May 2003 12:48:38 -0400 Received: from seraph3.grc.nasa.gov ([128.156.10.12]) by ietf-mx with esmtp (Exim 4.12) id 19HnoO-0004oa-00 for tsvwg@ietf.org; Mon, 19 May 2003 12:48:32 -0400 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 607746BA86 for ; Mon, 19 May 2003 12:48:16 -0400 (EDT) Received: from guns.lerc.nasa.gov (guns.grc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h4JGmFuW027930; Mon, 19 May 2003 12:48:15 -0400 (EDT) Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id MAA00715; Mon, 19 May 2003 12:48:15 -0400 (EDT) Message-Id: <200305191648.MAA00715@guns.lerc.nasa.gov> To: "Henderson, Thomas R" From: Mark Allman Reply-To: mallman@grc.nasa.gov Cc: "Randall Stewart" , "Armando L. Caro Jr." , "Sally Floyd" , "Kacheong Poon" , tsvwg@ietf.org Subject: Re: [Tsvwg] taking NewReno (RFC 2582) to Proposed Standard In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C01483D74@xch-nw-27.nw.nos.boeing.com> Organization: BBN Technologies/NASA GRC Song-of-the-Day: Lift Me Up Date: Mon, 19 May 2003 12:48:14 -0400 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , > > What if we allow slow start after doing the cut? > > > > My initial feeling is that it would cause a net reduction in the > overall sending rate, but how significant, I'm not sure: > > i) with maxburst, while you are limiting bursts, you are still > building cwnd further during that period, while with your slow > start proposal, you spend a few RTTs just getting back to the cwnd > you had, I am not sure I'd agree that when using maxburst and outstanding_data < cwnd you should be building your cwnd. That seems to be a violation of the spirit of CWV to me (i.e., TCP is not using (validating) what it has, why should it be allowed to build more?). > ii) by reducing cwnd, you are more vulnerable to additional > reductions = if a loss event occurs while you are trying to build > back up. So, if I read the above right ... Assume we use maxburst, outstanding_data=X and cwnd=X+Y (bigger because of the maxburst limiting). So, you're saying that if a loss event occurs we set cwnd to (X+Y)/2? (Whereas if we reduce cwnd we end up doing something like: cwnd=(X+maxburst)/2.) Do I have that right? If I do have that right then I disagree. I think that if you lose something when outstanding_data = X then you should be halving from X regardless of cwnd (i.e., cwnd = X/2). (And, in fact, this is what rfc2581 would call for.) To take an extreme example, assume X=Y and so cwnd = (2*outstanding_data) and there is a loss. If you just "cwnd /= 2" then you have not cut your sending rate at all. Or, maybe I am misreading your intention? Thanks! allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon May 19 13:24:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27929 for ; Mon, 19 May 2003 13:24:46 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4JGrnh01882 for tsvwg-archive@odin.ietf.org; Mon, 19 May 2003 12:53:49 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JGqBB01811; Mon, 19 May 2003 12:52:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JGonB01741 for ; Mon, 19 May 2003 12:50:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27791 for ; Mon, 19 May 2003 13:21:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19HoLa-00059s-00 for tsvwg@ietf.org; Mon, 19 May 2003 13:22:50 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx with esmtp (Exim 4.12) id 19HoLU-00059h-00 for tsvwg@ietf.org; Mon, 19 May 2003 13:22:45 -0400 Received: from slb-av-02.boeing.com ([129.172.13.7]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id KAA06152; Mon, 19 May 2003 10:23:03 -0700 (PDT) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-02.boeing.com (8.9.3p2/8.9.2/MBS-AV-02) with ESMTP id KAA04960; Mon, 19 May 2003 10:23:29 -0700 (PDT) Received: from XCH-NWBH-01.nw.nos.boeing.com (xch-nwbh-01.nw.nos.boeing.com [192.33.62.231]) by slb-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h4JHNRn05599; Mon, 19 May 2003 10:23:27 -0700 (PDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-01.nw.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6662); Mon, 19 May 2003 10:23:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Tsvwg] taking NewReno (RFC 2582) to Proposed Standard Date: Mon, 19 May 2003 10:23:26 -0700 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C01483D77@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [Tsvwg] taking NewReno (RFC 2582) to Proposed Standard Thread-Index: AcMeJn73xd566igCRVmplnKD+EmtmAAAgiDQ From: "Henderson, Thomas R" To: Cc: "Randall Stewart" , "Armando L. Caro Jr." , "Sally Floyd" , "Kacheong Poon" , X-OriginalArrivalTime: 19 May 2003 17:23:27.0456 (UTC) FILETIME=[5C206600:01C31E2B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4JGp4B01755 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > > ii) by reducing cwnd, you are more vulnerable to additional > > reductions = if a loss event occurs while you are trying to build > > back up. > > So, if I read the above right ... Assume we use maxburst, > outstanding_data=X and cwnd=X+Y (bigger because of the maxburst > limiting). So, you're saying that if a loss event occurs we set > cwnd to (X+Y)/2? (Whereas if we reduce cwnd we end up doing > something like: cwnd=(X+maxburst)/2.) Do I have that right? > > If I do have that right then I disagree. I think that if you lose > something when outstanding_data = X then you should be halving from > X regardless of cwnd (i.e., cwnd = X/2). (And, in fact, this is > what rfc2581 would call for.) yeah, you're right. > > Or, maybe I am misreading your intention? > If you think of this as a CWV case, in the sense that the sender is "ack-limited" rather than application-limited, then I would tend to agree that your proposal is more in the spirit of that. However, if you think about the intention of Reno, not requiring senders to reduce cwnd (or FlightSize) more than half for a single window's loss event, then one could argue for maxburst or rate-based pacing type of solutions. I have tended to think of it as the latter. But as we discuss this more, it seems to me that either your proposal #3 or the original maxburst proposal might end up being about the same in practice. Either one should reduce the burstiness problem that has been observed at the end of fast recovery. Maybe there is a high-speed TCP angle that makes more of a difference one way or another. Tom _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon May 19 15:47:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03749 for ; Mon, 19 May 2003 15:47:51 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4JJGvt12189 for tsvwg-archive@odin.ietf.org; Mon, 19 May 2003 15:16:57 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JJFcB12097; Mon, 19 May 2003 15:15:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JJE7B12030 for ; Mon, 19 May 2003 15:14:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03465 for ; Mon, 19 May 2003 15:44:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19HqaD-00066t-00 for tsvwg@ietf.org; Mon, 19 May 2003 15:46:05 -0400 Received: from cougar.icir.org ([192.150.187.76]) by ietf-mx with esmtp (Exim 4.12) id 19Hqa2-00066N-00 for tsvwg@ietf.org; Mon, 19 May 2003 15:45:54 -0400 Received: from cougar.icir.org (localhost [127.0.0.1]) by cougar.icir.org (8.12.8p1/8.12.3) with ESMTP id h4JJk0vo062542; Mon, 19 May 2003 12:46:00 -0700 (PDT) (envelope-from floyd@cougar.icir.org) Message-Id: <200305191946.h4JJk0vo062542@cougar.icir.org> To: "Henderson, Thomas R" cc: tsvwg@ietf.org From: Sally Floyd Subject: Re: [Tsvwg] taking NewReno (RFC 2582) to Proposed Standard Date: Mon, 19 May 2003 12:46:00 -0700 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , >> From: Armando L. Caro Jr. [mailto:acaro@mail.eecis.udel.edu] >> >> Yes, agreed. I think the right thing to do is to apply max >> burst always. >> No matter what, each ack may only trigger a send of at most Max.Burst >> packets. >> > >Does such a recommendation, if agreed, belong in a NewReno specific document? I agree that maxburst might be useful, but that a discussion of the general use of maxburst definitely doesn't belong in the NewReno document. Some observations on maxburst: Maxburst has been in the NS simulator forever, in the form of limiting how much is sent in response to a single ACK, not in the form of limiting the congestion window. Maxburst is turned off by default in NS. Maxburst is mostly useful for a path where the bottleneck queues use Drop-Tail, and therefore are sensitive to very small bursts in the sending rate. In a network where the bottleneck queues used some form of Active Queue Management, and therefore were properly robust to small-scale burstiness, I would expect that some TCP connections would perform better without maxburst. In the long run, one would like queues to perform robustly in the presence of small bursts. Maxburst is in some sense a cheap, coarse-grained version of rate-based pacing. And probably could generate the same set of papers detailing the cases where it is of benefit, and the cases where it isn't. For rate-based pacing, the papers include: Amit Aggarwal, Stefan Savage, and Tom Anderson, Understanding the Performance of TCP Pacing, Proceedings of the 2000 IEEE INFOCOM Conference, Tel-Aviv, Israel, March 2000. (I am not trying to denigrate maxburst, I think it might have been my idea, many years ago.) - Sally http://www.icir.org/floyd/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon May 19 20:29:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11392 for ; Mon, 19 May 2003 20:29:02 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4JNwD231567 for tsvwg-archive@odin.ietf.org; Mon, 19 May 2003 19:58:13 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JNuYB31508; Mon, 19 May 2003 19:56:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JNsWB31410 for ; Mon, 19 May 2003 19:54:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11286 for ; Mon, 19 May 2003 20:24:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Huxj-00000I-00 for tsvwg@ietf.org; Mon, 19 May 2003 20:26:39 -0400 Received: from parmesan.cs.wisc.edu ([128.105.167.16]) by ietf-mx with esmtp (Exim 4.12) id 19Huxi-00000F-00 for tsvwg@ietf.org; Mon, 19 May 2003 20:26:38 -0400 Received: (from poon@localhost) by parmesan.cs.wisc.edu (8.9.2/8.9.2) id TAA22092 for tsvwg@ietf.org; Mon, 19 May 2003 19:27:56 -0500 (CDT) Date: Mon, 19 May 2003 19:27:56 -0500 (CDT) From: Kacheong Poon Message-Id: <200305200027.TAA22092@parmesan.cs.wisc.edu> To: tsvwg@ietf.org Subject: Re: [Tsvwg] taking NewReno (RFC 2582) to Proposed Standard Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Included message from Mark Allman : >---- > * To my way of looking at things, scheme (1) uses two controls for > how much data can be sent into the network. That is, we can > either be limited by cwnd or we can be limited by maxburst. > > And, since there are two controls there are interactions between > them that must be taken into account -- in specs and code. And, > there are things that are currently speced that will break. > That is, TCP can be running in a state where there is less than > cwnd on the network because it is limited by maxburst instead of > cwnd and the specs/code do not envision the case and therefore > cannot be exepected to do something intelligent. > > An example of where this breaks things: The limited transmit > spec says that on dup acks TCP can inject at most cwnd+(2*MSS) > of new data into the network. The hope was that this means that > we can send data on the first two dup acks. If maxburst has > limited the amount of outstanding data to something less than > cwnd then limited transmit now allows the sending of more than > two new segments on dup ACKs. That might be OK. But, I think > that is clearly at odds with the spirit of RFC 3042. I think > there are likely quite a number of examples of unintended > interactions/consequences. > > But, that can be fixed... we can set a flag, add some > conditionals, some temporary variables, write some new text and > plug up these things right up... Hmm, this seems like a hole in how the Limited Transmit algorithm is described. Basically, what Limited Transmit wants is to send two new segments out, one per dup ACK, if allowed by rwnd. Since TCP will never send more than cwnd allows, RFC 3042 can just say "send one new segment per dup ACK" instead of mentioning anything about the number of outstanding segments in the network is at most cwnd+2*SMSS. This will avoid the pitfall described above. There is no need to introduce new temporary variables, write some new text or plug up things... > * On the other hand, scheme (2) has only a single controller. We > are always limited by cwnd -- and, maxburst is just an input to > this controller. On the surface, the above snippets of code may > look the same, but they are not. If you take the limited > transmit case again... LT has no problem under scheme (2) > because the cwnd is now tracking the amount of outstanding data. > All of our code and our specs this to be the way things are. > So, this works nicely. I guess we should separate the algorithm from code for a moment. Assuming Limited Transmit was described as I suggested above, would the maxburst variable affect it? I guess not. So it becomes an implementation error if the maxburst variable actually affects Limited Transmit. It works nicely as well (-: > * Now let me take a minute and say that (a) I do not care for the > downsides of scheme (2) that Sally illustrated and (b) I think > that scheme (1) is equally bogus because it adds a second > control for the amount of outstanding data -- and no end of > headaches will come of it. Also, I do not buy that because TCP > sends "micro" and "macro" bursts that we should have two > controllers for these sending patterns. It makes no sense to me > since in the end they control the same thing: the amount of data > that can be dumped into the network. Well, if Mark does not care about problems with scheme (2), there is no need for discussion (-: I guess we should forget about that there is actually a variable called maxburst and scheme (2) for a moment. Consider this case, an app using TCP has a brief moment (much shorter than one RTT) of pause such that the number of outstanding segments in the network is less than the current cwnd. Should TCP reduce the cwnd because of this? I guess most, if not all, people agree that cwnd should probably be reduced if the pause is longer than one RTT, as described in RFC 2861. This is the idea behind "Use-it or Lose-it." But for a period less than one RTT, I suspect that most people will say no. Using the variable maxburst, there is no effect on cwnd in the above case. It still tracks the current "macro" sending rate and I guess most people are happy with that. In fact, maxburst is kind of like an "artifical app pause" in other cases as described in this mail thread. Using scheme (2), TCP will immediately forget about the current sending rate and start the whole slow start process once again. Do most people agree that it is the appropriate action, especially in the case with long RTT, such as satellite link? > * So, the question I am left puzzling over is: can we combine > schemes (1) and (2) in a sensible way to avoid the downsides > that Sally has shown while also avoiding a second control on > outstanding data? But I guess we should first ask ourself if scheme (2) is actually a good thing to do before tackling the above question. > * One more observation: If maxburst is 4, we use scheme (1), we > use delayed ACKs, cwnd = outstanding_data = 10 segments and we > get an ACK that covers 10 previously unACKed segments (because > of dropped ACKs) the events will look like this: > > get ACK for 10 segments; send 4 segments > (outstanding = 4; cwnd = 10) > get ACK for 2 segments; send 4 segments > (outstanding = 6; cwnd = 10) > get ACK for 2 segments; send 4 segments > (outstanding = 8; cwnd = 10) > get ACK for 2 segments; send 4 segments > (outstanding = 10; cwnd = 10) > get ACK for 2 segments; send 2 segments > (outstanding = 10; cwnd = 10) > > I.e., it's slow start. > > * So, what if we introduce a scheme (3), which is really just a > riff of scheme (2): > > if ((outstanding_data + maxburst) < cwnd) > if (ssthresh < cwnd) > ssthresh = cwnd > cwnd = outstanding_data + maxburst > while (outstanding_data < cwnd) > send_segment () > outstanding_data++ > > In other words, we clamp cwnd to limit the burst, but we also > set ssthresh in such a way that we can slow start to climb out > of the cwnd reduction. > > It is late, but I think this gives us the good points of (1) and > (2) -- that is, one controller with the same basic pattern of > sending given by scheme (1). > >Thoughts? Hmm, I guess you want to simplify things... But it seems to me that the above actually make things more complicated. What do we gain? >[Also, with appologies to Joe Touch & Amy Hughes --- who probably > had all this figured out long ago (but, their exact ideas have > fallen out of my head.] Yeah, I remembered Joe Touch mentioned something at one IETF long ago and said that he would write up a draft or something. But I don't know if that actually happened... >---- K. Poon. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon May 19 21:02:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12011 for ; Mon, 19 May 2003 21:02:18 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4K0VUH01097 for tsvwg-archive@odin.ietf.org; Mon, 19 May 2003 20:31:30 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4K0U9B01051; Mon, 19 May 2003 20:30:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4K0TuB01026 for ; Mon, 19 May 2003 20:29:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11941 for ; Mon, 19 May 2003 21:00:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19HvVz-0000B5-00 for tsvwg@ietf.org; Mon, 19 May 2003 21:02:03 -0400 Received: from parmesan.cs.wisc.edu ([128.105.167.16]) by ietf-mx with esmtp (Exim 4.12) id 19HvVy-0000B2-00 for tsvwg@ietf.org; Mon, 19 May 2003 21:02:02 -0400 Received: (from poon@localhost) by parmesan.cs.wisc.edu (8.9.2/8.9.2) id UAA22216 for tsvwg@ietf.org; Mon, 19 May 2003 20:03:21 -0500 (CDT) Date: Mon, 19 May 2003 20:03:21 -0500 (CDT) From: Kacheong Poon Message-Id: <200305200103.UAA22216@parmesan.cs.wisc.edu> To: tsvwg@ietf.org Subject: RE: [Tsvwg] taking NewReno (RFC 2582) to Proposed Standard Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Included message from "Henderson, Thomas R" : >---- >> -----Original Message----- >> From: Armando L. Caro Jr. [mailto:acaro@mail.eecis.udel.edu] >> >> Yes, agreed. I think the right thing to do is to apply max >> burst always. >> No matter what, each ack may only trigger a send of at most Max.Burst >> packets. >> > >Does such a recommendation, if agreed, belong in a NewReno specific document? It seems to me that this does not belong to the NewReno document as it is not specific to NewReno. But as a data point, Solaris' TCP apply some form of max burst always for many years. And I have not heard any complaints. So I guess it is OK. >Another issue that may or may not be NewReno specific is whether it is a good >idea to recommend suppressing the sending of pure window updates intermingled >with dupacks, to avoid resetting the counter to enter fast retransmit (Jeffrey >Hsu mentioned this to me earlier this week). This probably is not an issue >when SACK is used. Does this happen often? When this happens, does the opening up of the window also trigger new segments to be sent? And is the effect really bad? >---- K. Poon. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon May 19 23:14:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14180 for ; Mon, 19 May 2003 23:14:55 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4K2iBb09831 for tsvwg-archive@odin.ietf.org; Mon, 19 May 2003 22:44:11 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4K2gZB09776; Mon, 19 May 2003 22:42:35 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4K2fnB09747 for ; Mon, 19 May 2003 22:41:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14109 for ; Mon, 19 May 2003 23:12:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19HxZZ-0000gw-00 for tsvwg@ietf.org; Mon, 19 May 2003 23:13:53 -0400 Received: from d14-69-204-117.clv.wideopenwest.com ([69.14.117.204] helo=lawyers.ir.bbn.com) by ietf-mx with esmtp (Exim 4.12) id 19HxZY-0000go-00 for tsvwg@ietf.org; Mon, 19 May 2003 23:13:52 -0400 Received: by lawyers.ir.bbn.com (Postfix, from userid 9076) id A49D66B2B4; Mon, 19 May 2003 23:00:40 -0400 (EDT) To: Kacheong Poon From: Mark Allman Reply-To: mallman@grc.nasa.gov Cc: tsvwg@ietf.org Subject: Re: [Tsvwg] taking NewReno (RFC 2582) to Proposed Standard In-Reply-To: <200305200027.TAA22092@parmesan.cs.wisc.edu> Organization: BBN Technologies/NASA GRC Song-of-the-Day: Lift Me Up Date: Mon, 19 May 2003 23:00:40 -0400 Message-Id: <20030520030040.A49D66B2B4@lawyers.ir.bbn.com> Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , > > But, that can be fixed... we can set a flag, add some > > conditionals, some temporary variables, write some new text and > > plug up these things right up... > > Hmm, this seems like a hole in how the Limited Transmit algorithm > is described. Basically, what Limited Transmit wants is to send > two new segments out, one per dup ACK, if allowed by rwnd. Since > TCP will never send more than cwnd allows, RFC 3042 can just say > "send one new segment per dup ACK" instead of mentioning anything > about the number of outstanding segments in the network is at most > cwnd+2*SMSS. This will avoid the pitfall described above. There > is no need to introduce new temporary variables, write some new > text or plug up things... You made my point. If we are to use a simple maxburst limit then the limited transmit rfc has a "hole" and we do need new text. It might not be complicated, but it will become busted and in need of a fix. And, LT was only an example. My bet is that we have to revist a bunch of things for similar reasons. And, as we evolve things we're going to have to remain cognizant that now we have two things controlling the amount of data being sent into the network (possibly requiring two different decision paths, etc.). > I guess we should separate the algorithm from code for a moment. > Assuming Limited Transmit was described as I suggested above, > would the maxburst variable affect it? I guess not. So it becomes > an implementation error if the maxburst variable actually affects > Limited Transmit. It works nicely as well (-: Hm, if one were to implement rfc3042 and we reach consensus that said implementation did the wrong thing it would be more than an implementation error -- it would be a spec error. > Consider this case, an app using TCP has a brief moment (much > shorter than one RTT) of pause such that the number of outstanding > segments in the network is less than the current cwnd. Should TCP > reduce the cwnd because of this? I guess most, if not all, people > agree that cwnd should probably be reduced if the pause is longer > than one RTT, as described in RFC 2861. This is the idea behind > "Use-it or Lose-it." But for a period less than one RTT, I > suspect that most people will say no. > > Using the variable maxburst, there is no effect on cwnd in the above > case. It still tracks the current "macro" sending rate and I > guess most people are happy with that. In fact, maxburst is kind > of like an "artifical app pause" in other cases as described in this > mail thread. Using scheme (2), TCP will immediately forget about > the current sending rate and start the whole slow start process once > again. Do most people agree that it is the appropriate action, > especially in the case with long RTT, such as satellite link? The problem is that discussing things only in terms of cwnd misses the whole point. Of course, it might be natural to think "ah, I don't want to sacrifice cwnd". But, by limiting the bursts in response to each ACK we are basically doing exactly the same thing --- that is, we are limiting the amount of data that can be put on the wire. I agree that scheme (2) is somewhat naive -- as folk have been saying. But, with scheme (3) (which is a slight riff on scheme (2)) I bet we see basically the same sort of behavior as scheme (1) and with the bonus that (a) we only use one control and so interactions are nil and (b) cwnd tracks the amount of outstanding data, which is in better alignment with the expectations of our code and specs. > >[Also, with appologies to Joe Touch & Amy Hughes --- who probably > > had all this figured out long ago (but, their exact ideas have > > fallen out of my head.] > > Yeah, I remembered Joe Touch mentioned something at one IETF long > ago and said that he would write up a draft or something. But I > don't know if that actually happened... (Joe and Amy did have a draft and did discuss it in tcpimpl a bit a while back. The tcpimpl archives are at: http://tcp-impl.grc.nasa.gov/tcp-impl) allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue May 20 00:02:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14182 for ; Mon, 19 May 2003 23:14:56 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4K2iBY09844 for tsvwg-archive@odin.ietf.org; Mon, 19 May 2003 22:44:11 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4K2gjB09796; Mon, 19 May 2003 22:42:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4K2fnB09749 for ; Mon, 19 May 2003 22:41:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14108 for ; Mon, 19 May 2003 23:12:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19HxZZ-0000gt-00 for tsvwg@ietf.org; Mon, 19 May 2003 23:13:53 -0400 Received: from d14-69-204-117.clv.wideopenwest.com ([69.14.117.204] helo=lawyers.ir.bbn.com) by ietf-mx with esmtp (Exim 4.12) id 19HxZY-0000gp-00 for tsvwg@ietf.org; Mon, 19 May 2003 23:13:52 -0400 Received: by lawyers.ir.bbn.com (Postfix, from userid 9076) id 601396B17A; Mon, 19 May 2003 22:46:53 -0400 (EDT) To: "Henderson, Thomas R" From: Mark Allman Reply-To: mallman@grc.nasa.gov Cc: "Randall Stewart" , "Armando L. Caro Jr." , "Sally Floyd" , "Kacheong Poon" , tsvwg@ietf.org Subject: Re: [Tsvwg] taking NewReno (RFC 2582) to Proposed Standard In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C01483D77@xch-nw-27.nw.nos.boeing.com> Organization: BBN Technologies/NASA GRC Song-of-the-Day: Lift Me Up Date: Mon, 19 May 2003 22:46:53 -0400 Message-Id: <20030520024653.601396B17A@lawyers.ir.bbn.com> Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , > If you think of this as a CWV case, in the sense that the sender is > "ack-limited" rather than application-limited, then I would tend to > agree that your proposal is more in the spirit of that. However,=20 > if you think about the intention of Reno, not requiring senders to=20 > reduce cwnd (or FlightSize) more than half for a single window's=20 > loss event, then one could argue for maxburst or rate-based pacing=20 > type of solutions. I have tended to think of it as the latter. Ah, ok... That's a nice description. I think I have a handle on the two ways to look at this now. (I still think the former is the way to go if one were to want a generalized burst controller... but, I understand the thinking behind the latter.) > But as we discuss this more, it seems to me that either your proposal=20 > #3 or the original maxburst proposal might end up being about the=20 > same in practice. Either one should reduce the burstiness problem > that has been observed at the end of fast recovery. Maybe there is=20 > a high-speed TCP angle that makes more of a difference one way or = > another. I'd very much like to know of such implications, too. Thanks! allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue May 20 00:11:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15241 for ; Tue, 20 May 2003 00:11:57 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4K3fCW13580 for tsvwg-archive@odin.ietf.org; Mon, 19 May 2003 23:41:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4K3dYB13504; Mon, 19 May 2003 23:39:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4K3c7B13460 for ; Mon, 19 May 2003 23:38:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15207 for ; Tue, 20 May 2003 00:08:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19HyS2-0000yR-00 for tsvwg@ietf.org; Tue, 20 May 2003 00:10:10 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx with esmtp (Exim 4.12) id 19HyS1-0000yO-00 for tsvwg@ietf.org; Tue, 20 May 2003 00:10:09 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id XAA19727; Mon, 19 May 2003 23:11:27 -0500 (CDT) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.9.3p2/8.9.2/MBS-AV-02) with ESMTP id XAA18219; Mon, 19 May 2003 23:11:26 -0500 (CDT) Received: from XCH-NWBH-01.nw.nos.boeing.com (xch-nwbh-01.nw.nos.boeing.com [192.33.62.231]) by slb-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h4K4BPB11221; Mon, 19 May 2003 21:11:25 -0700 (PDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-01.nw.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6662); Mon, 19 May 2003 21:11:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Tsvwg] taking NewReno (RFC 2582) to Proposed Standard Date: Mon, 19 May 2003 21:11:24 -0700 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C020ABF32@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [Tsvwg] taking NewReno (RFC 2582) to Proposed Standard Thread-Index: AcMebHkNc0ttWRSBQ2uwZvuUi60CvAAF06ug From: "Henderson, Thomas R" To: "Kacheong Poon" , X-OriginalArrivalTime: 20 May 2003 04:11:24.0934 (UTC) FILETIME=[E0E8C260:01C31E85] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4K3c7B13461 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Kacheong Poon [mailto:poon@cs.wisc.edu] > Sent: Monday, May 19, 2003 6:03 PM > To: tsvwg@ietf.org > Subject: RE: [Tsvwg] taking NewReno (RFC 2582) to Proposed Standard > > > >Another issue that may or may not be NewReno specific is > whether it is a good > >idea to recommend suppressing the sending of pure window > updates intermingled > >with dupacks, to avoid resetting the counter to enter fast > retransmit (Jeffrey > >Hsu mentioned this to me earlier this week). This probably > is not an issue > >when SACK is used. > > Does this happen often? When this happens, does the opening up > of the window also trigger new segments to be sent? And is the > effect really bad? > I don't know how often it happens. However, it could be tricky to intelligently suppress these, because if the sender is not yet in Fast Recovery, it would be better to suppress them, but if the sender is in Fast Recovery, you would want to send pure window updates so that true dupacks cause a new segment to be sent off the top of the window (in some recent testing, I observed cases in which pure window updates were not sent by the receiver, leading to dupacks being interpreted by the sender (in Fast Recovery) as being window updates, causing FlightSize to be much less than cwnd upon leaving Fast Recovery, causing a burst of data, leading to thinking about maxburst...) Another way of looking at this is that if window updates are sometimes suppressed, how does the sender know when a dupack arrives with a different window than the previous, whether to interpret it as a dupack triggered by an out-of-order segment or whether it is a window update? And then there is the issue of dealing with heterogeneous (legacy) implementations if a change is made. Tom _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue May 20 13:45:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22697 for ; Tue, 20 May 2003 13:45:47 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4KHCBR19471 for tsvwg-archive@odin.ietf.org; Tue, 20 May 2003 13:12:11 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4KHA5B19416; Tue, 20 May 2003 13:10:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4KH6cB18350 for ; Tue, 20 May 2003 13:06:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22479 for ; Tue, 20 May 2003 13:39:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IB4B-00078c-00 for tsvwg@ietf.org; Tue, 20 May 2003 13:38:23 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx with esmtp (Exim 4.12) id 19IB4B-00078K-00 for tsvwg@ietf.org; Tue, 20 May 2003 13:38:23 -0400 Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h4KHdCC06851; Tue, 20 May 2003 17:39:12 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 20 May 2003 13:39:17 -0400 Message-ID: <0449D80A0E9B614A83FA9031B07E8D3B257A95@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'tsvwg@ietf.org'" Cc: "'mankin@psg.com'" Date: Tue, 20 May 2003 13:39:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Tsvwg] WGLC for draft-blanton-dsack-use-02 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , The chairs would like to announce a two week working group last call for draft-blanton-dsack-use-02. Please direct any comments to this mailing list. Note that the draft name will be updated to reflect that it is a working group item of the TSVWG after the conclusion of last call. Jon Peterson NeuStar, Inc. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue May 20 22:08:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08475 for ; Tue, 20 May 2003 22:08:29 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4L1Z4v23239 for tsvwg-archive@odin.ietf.org; Tue, 20 May 2003 21:35:04 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4L1XeB23156; Tue, 20 May 2003 21:33:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4J8HwB28903 for ; Mon, 19 May 2003 04:17:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12506 for ; Mon, 19 May 2003 04:48:35 -0400 (EDT) From: mrajpal@hss.hns.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19HgLh-0001D5-00 for tsvwg@ietf.org; Mon, 19 May 2003 04:50:25 -0400 Received: from hindon.hss.co.in ([202.54.26.202]) by ietf-mx with esmtp (Exim 4.12) id 19HgLg-0001Cz-00 for tsvwg@ietf.org; Mon, 19 May 2003 04:50:24 -0400 Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h4J8miZ12996 for ; Mon, 19 May 2003 14:18:44 +0530 (IST) Received: from ultra.hss.co.in (ultra [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h4J8mX912912; Mon, 19 May 2003 14:18:33 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id h4J8pnU25542; Mon, 19 May 2003 14:21:49 +0530 (IST) To: tsvwg@ietf.org Cc: sctp-impl@external.cisco.com Date: Mon, 19 May 2003 14:17:20 +0530 Message-ID: X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 19/05/2003 02:16:16 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [Tsvwg] clarification required for sctp socket draft 06 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , hi, In section 5.3.1.1 of draft-ietf-tsvwg-sctpsocket-06.txt,, the structure definiition is struct sctp_assoc_change { uint16_t sac_type; uint16_t sac_flags; uint32_t sac_length; uint16_t sac_state; uint16_t sac_error; uint16_t sac_outbound_streams; uint16_t sac_inbound_streams; sctp_assoc_t sac_assoc_id; uint8_t sac_info[0]; }; The last member sac_info is mentioned as sac_data in the description given in the same section. Please clarify what should be the member called, sac_info or sac_data. regards manish Hughes Software Systems http://www.hssworld.com "DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue May 20 23:40:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09984 for ; Tue, 20 May 2003 23:40:36 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4L37DA29137 for tsvwg-archive@odin.ietf.org; Tue, 20 May 2003 23:07:13 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4L35ZB28757; Tue, 20 May 2003 23:05:35 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4L34gB28725 for ; Tue, 20 May 2003 23:04:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09971 for ; Tue, 20 May 2003 23:37:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IKOl-0002k4-00 for tsvwg@ietf.org; Tue, 20 May 2003 23:36:15 -0400 Received: from parmesan.cs.wisc.edu ([128.105.167.16]) by ietf-mx with esmtp (Exim 4.12) id 19IKOl-0002k1-00 for tsvwg@ietf.org; Tue, 20 May 2003 23:36:15 -0400 Received: (from poon@localhost) by parmesan.cs.wisc.edu (8.9.2/8.9.2) id WAA27182 for tsvwg@ietf.org; Tue, 20 May 2003 22:37:35 -0500 (CDT) Date: Tue, 20 May 2003 22:37:35 -0500 (CDT) From: Kacheong Poon Message-Id: <200305210337.WAA27182@parmesan.cs.wisc.edu> To: tsvwg@ietf.org Subject: Re: [Tsvwg] taking NewReno (RFC 2582) to Proposed Standard Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Included message from Mark Allman : >---- >You made my point. If we are to use a simple maxburst limit then >the limited transmit rfc has a "hole" and we do need new text. It >might not be complicated, but it will become busted and in need of a >fix. And, LT was only an example. My bet is that we have to revist >a bunch of things for similar reasons. And, as we evolve things >we're going to have to remain cognizant that now we have two things >controlling the amount of data being sent into the network (possibly >requiring two different decision paths, etc.). Since you said that "I made your point," I guess you agreed that there is a hole in RFC 3042 (-: As I mentioned in my previous mail, maxburst is an "artificial app pause." Any app which has a pause in sending will behave similarly. Your example arguing that maxburst is bad for Limited Transmit applies equally to an app which has a pause in sending. So I guess most people will agree that the problem you referred to with maxburst is actually an issue in RFC 3042, not with maxburst. >Hm, if one were to implement rfc3042 and we reach consensus that >said implementation did the wrong thing it would be more than an >implementation error -- it would be a spec error. Yes, it is a spec error in RFC 3042. We still have time to fix it, right? >The problem is that discussing things only in terms of cwnd misses >the whole point. Of course, it might be natural to think "ah, I >don't want to sacrifice cwnd". But, by limiting the bursts in >response to each ACK we are basically doing exactly the same thing >--- that is, we are limiting the amount of data that can be put on >the wire. > >I agree that scheme (2) is somewhat naive -- as folk have been >saying. > >But, with scheme (3) (which is a slight riff on scheme (2)) I bet we >see basically the same sort of behavior as scheme (1) and with the >bonus that (a) we only use one control and so interactions are nil >and (b) cwnd tracks the amount of outstanding data, which is in >better alignment with the expectations of our code and specs. Scheme (3) is actually worse than (2) IMHO. Besides overloading the meaning of cwnd, it also overloads the meaning of ssthresh. The variable ssthresh is used to track (or approximate) the number of segments the network path to a destination can take before congestion may happen. Scheme (3) removes this meaning altogether. This changes the whole mechanism of TCP probing the network to test for congestion point. And we are talking about unknown interactions in this email thread! In general, I strongly disagree with semantics overloading. And if we are solely concerned about the unknown interactions introduced by maxburst, let me give a data point. Solaris' TCP has had maxburst since 1998. AFAIK, there is no complaint about it. If we believe in running code, I think maxburst is OK. OTOH, we already know that scheme (2) is not good. And the proposed scheme (3) will change TCP congestion control behavior. So which one will more likely have unknown interactions? >---- K. Poon. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Wed May 21 00:15:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10604 for ; Wed, 21 May 2003 00:15:14 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4L3fq731619 for tsvwg-archive@odin.ietf.org; Tue, 20 May 2003 23:41:52 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4L3eSB31593; Tue, 20 May 2003 23:40:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4L3d9B31527 for ; Tue, 20 May 2003 23:39:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10568 for ; Wed, 21 May 2003 00:12:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IKw5-0002rr-00 for tsvwg@ietf.org; Wed, 21 May 2003 00:10:41 -0400 Received: from d14-69-204-117.clv.wideopenwest.com ([69.14.117.204] helo=lawyers.ir.bbn.com) by ietf-mx with esmtp (Exim 4.12) id 19IKw4-0002ro-00 for tsvwg@ietf.org; Wed, 21 May 2003 00:10:40 -0400 Received: by lawyers.ir.bbn.com (Postfix, from userid 9076) id 3C0B96B17A; Wed, 21 May 2003 00:11:54 -0400 (EDT) To: Kacheong Poon From: Mark Allman Reply-To: mallman@grc.nasa.gov Cc: tsvwg@ietf.org Subject: Re: [Tsvwg] taking NewReno (RFC 2582) to Proposed Standard In-Reply-To: <200305210337.WAA27182@parmesan.cs.wisc.edu> Organization: BBN Technologies/NASA GRC Song-of-the-Day: If I Wanted To Date: Wed, 21 May 2003 00:11:53 -0400 Message-Id: <20030521041154.3C0B96B17A@lawyers.ir.bbn.com> Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , > Since you said that "I made your point," I guess you agreed that > there is a hole in RFC 3042 (-: Not necessarily.... there would be a hole with maxburst. > As I mentioned in my previous mail, maxburst is an "artificial app > pause." Any app which has a pause in sending will behave > similarly. Indeed that could very well lead to a "hole" in LT. (Which would be exacerbated by maxburst -- or, by anything that dropped the outstanding data to less than the cwnd.) My over-arching point is not about LT, though -- but, that we'd carefully have to consider all sorts of things to find new problems caused that a maxburst would cause. > Scheme (3) is actually worse than (2) IMHO. Besides overloading > the meaning of cwnd, it also overloads the meaning of ssthresh. > The variable ssthresh is used to track (or approximate) the number > of segments the network path to a destination can take before > congestion may happen. Scheme (3) removes this meaning > altogether. This changes the whole mechanism of TCP probing the > network to test for congestion point. And we are talking about > unknown interactions in this email thread! First, I do not agree with your notions of either cwnd or ssthresh. I believe that cwnd is the amount of outstanding data a TCP can have in the network at any given instant (and, any number of things can be used as inputs -- estimated path capacity, burst capacity, etc.). And, ssthresh is just the pivot point for slow start (exponential growth vs. linear growth). E.g., we use ssthresh for history in CWV. That is all I am suggesting here, as well. Given those notions I do not see why cwnd cannot be used to help mitigate bursts. And, I do not agree that we are "overloading" the meaning of these variables. But, even if we use your notion of ssthresh as the amount of traffic the network can take before congestion happens I still think using ssthresh in the manner I sketched is consistent. I.e., if we build cwnd to some value X without congestion and then set ssthresh to that value then that would seem to fall within your definition. > And if we are solely concerned about the unknown interactions > introduced by maxburst, let me give a data point. Solaris' TCP > has had maxburst since 1998. AFAIK, there is no complaint about > it. If we believe in running code, I think maxburst is OK. Data point taken. But, "No complaint" is not so convincing to me... has anyone studied it? And, all TCP's bend things around their own special way (e.g., solaris uses maxburst even though it is not standard; although, it is also not non-standard given that it is more conservative than the spec calls for). So, it might be that solaris TCP also contains not-quite-standard ways of doing other things that get around the interactions. Maybe not. But, maybe. I'd want to see a pretty in-depth study so I could understand what solaris is doing. (That is, I'd like to underestand the running code, not just be happy that we have it.) > OTOH, we already know that scheme (2) is not good. And the > proposed scheme (3) will change TCP congestion control behavior. > So which one will more likely have unknown interactions? Finally, contrary to what you note above, I think the interactions of scheme (3) are quite well known since they are just the same old TCP interactions. There are no new dynamics here, just a cwnd reduction followed by a slow start. Nothing unusal about that. What implications do you see? allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu May 22 02:23:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01869 for ; Thu, 22 May 2003 02:23:10 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4M5oIe23360 for tsvwg-archive@odin.ietf.org; Thu, 22 May 2003 01:50:18 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4M5mOB23283; Thu, 22 May 2003 01:48:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4M5kIB23208 for ; Thu, 22 May 2003 01:46:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01680 for ; Thu, 22 May 2003 02:18:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IjO9-0005fi-00 for tsvwg@ietf.org; Thu, 22 May 2003 02:17:17 -0400 Received: from parmesan.cs.wisc.edu ([128.105.167.16]) by ietf-mx with esmtp (Exim 4.12) id 19IjO9-0005ff-00 for tsvwg@ietf.org; Thu, 22 May 2003 02:17:17 -0400 Received: (from poon@localhost) by parmesan.cs.wisc.edu (8.9.2/8.9.2) id BAA32280 for tsvwg@ietf.org; Thu, 22 May 2003 01:18:39 -0500 (CDT) Date: Thu, 22 May 2003 01:18:39 -0500 (CDT) From: Kacheong Poon Message-Id: <200305220618.BAA32280@parmesan.cs.wisc.edu> To: tsvwg@ietf.org Subject: Re: [Tsvwg] taking NewReno (RFC 2582) to Proposed Standard Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu May 22 02:23:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01883 for ; Thu, 22 May 2003 02:23:11 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4M5oJ623374 for tsvwg-archive@odin.ietf.org; Thu, 22 May 2003 01:50:19 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4M5n2B23303; Thu, 22 May 2003 01:49:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4M5lFB23237 for ; Thu, 22 May 2003 01:47:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01774 for ; Thu, 22 May 2003 02:19:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IjP4-0005g0-00 for tsvwg@ietf.org; Thu, 22 May 2003 02:18:14 -0400 Received: from parmesan.cs.wisc.edu ([128.105.167.16]) by ietf-mx with esmtp (Exim 4.12) id 19IjP3-0005fx-00 for tsvwg@ietf.org; Thu, 22 May 2003 02:18:13 -0400 Received: (from poon@localhost) by parmesan.cs.wisc.edu (8.9.2/8.9.2) id BAA32284 for tsvwg@ietf.org; Thu, 22 May 2003 01:19:36 -0500 (CDT) Date: Thu, 22 May 2003 01:19:36 -0500 (CDT) From: Kacheong Poon Message-Id: <200305220619.BAA32284@parmesan.cs.wisc.edu> To: tsvwg@ietf.org Subject: Re: [Tsvwg] taking NewReno (RFC 2582) to Proposed Standard Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Included message from Mark Allman : >Indeed that could very well lead to a "hole" in LT. > >(Which would be exacerbated by maxburst -- or, by anything that >dropped the outstanding data to less than the cwnd.) > >My over-arching point is not about LT, though -- but, that we'd >carefully have to consider all sorts of things to find new problems >caused that a maxburst would cause. Let me quote what I wrote in a previous email and ask what people on this list think. ---- Consider this case, an app using TCP has a brief moment (much shorter than one RTT) of pause such that the number of outstanding segments in the network is less than the current cwnd. Should TCP reduce the cwnd because of this? I guess most, if not all, people agree that cwnd should probably be reduced if the pause is longer than one RTT, as described in RFC 2861. This is the idea behind "Use-it or Lose-it." But for a period less than one RTT, I suspect that most people will say no. ---- Do most people agree with the last statement? I guess this summarizes what I've been trying to say about maxburst. I don't know if people on this list really want to change how TCP works with temporary app pause. But it is very clear that RFC 3042 has a problem in how the algorithm is specified. [ ... ] >Finally, contrary to what you note above, I think the interactions >of scheme (3) are quite well known since they are just the same old >TCP interactions. There are no new dynamics here, just a cwnd >reduction followed by a slow start. Nothing unusal about that. >What implications do you see? I believe the particular TCP mechanism Mark referred above happens when there is a drop, which indicates that there is congestion (assuming drop implies congestion). In the context we are discussing here, the experiemental CWV does not apply (refer to the above quote). So if you are saying that this does not change TCP's behavior regarding temporary app pause in a way that people are not used to... I suggest Mark to write up a paper describing his idea with data supporting what he tries to say. I'm afraid we are just expressing opinions here without fruitful results, except that RFC 3042 needs some changes.... K. Poon. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu May 22 05:17:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05530 for ; Thu, 22 May 2003 05:17:43 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4M8iuL15448 for tsvwg-archive@odin.ietf.org; Thu, 22 May 2003 04:44:56 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4M8hQB15264; Thu, 22 May 2003 04:43:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4M8gSB15214 for ; Thu, 22 May 2003 04:42:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05343 for ; Thu, 22 May 2003 05:14:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Im8Z-0006qF-00 for tsvwg@ietf.org; Thu, 22 May 2003 05:13:23 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19Im8Y-0006qB-00 for tsvwg@ietf.org; Thu, 22 May 2003 05:13:22 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h4M9Ej701364 for ; Thu, 22 May 2003 12:14:45 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 22 May 2003 12:14:43 +0300 Received: from sahaja.research.nokia.com ([172.21.40.118]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 22 May 2003 12:14:43 +0300 Subject: Re: [Tsvwg] taking NewReno (RFC 2582) to Proposed Standard From: Pasi Sarolahti To: ext Kacheong Poon Cc: tsvwg@ietf.org In-Reply-To: <200305220619.BAA32284@parmesan.cs.wisc.edu> References: <200305220619.BAA32284@parmesan.cs.wisc.edu> Content-Type: text/plain Organization: Nokia Research Center Message-Id: <1053594882.21937.84.camel@optiplex> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 22 May 2003 12:14:43 +0300 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 May 2003 09:14:43.0342 (UTC) FILETIME=[94D4F2E0:01C32042] Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all, On Thu, 2003-05-22 at 09:19, ext Kacheong Poon wrote: > Let me quote what I wrote in a previous email and ask > what people on this list think. > > ---- > Consider this case, an app using TCP has a brief moment > (much shorter than one RTT) of pause such that the number of > outstanding segments in the network is less than the current cwnd. > Should TCP reduce the cwnd because of this? I guess most, if not > all, people agree that cwnd should probably be reduced if the pause > is longer than one RTT, as described in RFC 2861. This is the idea > behind "Use-it or Lose-it." But for a period less than one RTT, I > suspect that most people will say no. > ---- > > Do most people agree with the last statement? [Since you asked... Even though I doubt I can bring much new to this thread] I think some kind of burst avoidance is needed as a general safety mechanism, not only considering NewReno. I like Mark's suggestion (3), because it seems to behave similarly than alternative (1) with separate control variable, and can do this with existing TCP variables (well, at least as long as maxburst <= 3). So, I think momentarily reducing cwnd is ok, if the pitfalls described earlier related to reordering, etc. can be avoided. There seems to be different opinions in what kind of role cwnd should have. I'd like to keep it simple: while cwnd > flightsize send data; otherwise don't send data. Additional variables to that add complexity. However, I do see that if cwnd is strictly thought of as an higher level parameter ("my fair share of the network capacity"), reducing it as you describe above does not sound a good idea, even if it is known to be increased back in slow start within a short while. [Although there is an opposite case not directly related to this discussion: RFC 2581 and RFC 2582 momentarily increase cwnd during fast recovery to allow forward transmissions, even though the actual congestion window should really be something less at that moment] But in the end, I think it is mostly an implementation issue to choose the most suitable variant of the actual burst avoidance algorithm. As long as the TCP congestion control RFC requires burst avoidance and describes what is meant by burst avoidance either by using (1) or (3), it should be ok, right? - Pasi _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri May 23 12:40:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12177 for ; Fri, 23 May 2003 12:40:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4NGdfR29262 for tsvwg-archive@odin.ietf.org; Fri, 23 May 2003 12:39:41 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4NGbWB28829; Fri, 23 May 2003 12:37:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4MG1tB22809 for ; Thu, 22 May 2003 12:01:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20344 for ; Thu, 22 May 2003 12:34:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Iszh-0003FC-00 for tsvwg@ietf.org; Thu, 22 May 2003 12:32:41 -0400 Received: from seraph3.grc.nasa.gov ([128.156.10.12]) by ietf-mx with esmtp (Exim 4.12) id 19Iszh-0003F3-00 for tsvwg@ietf.org; Thu, 22 May 2003 12:32:41 -0400 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id B74B76BA84 for ; Thu, 22 May 2003 12:33:34 -0400 (EDT) Received: from lawyers.ir.bbn.com (lawyers.grc.nasa.gov [139.88.122.87]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h4MGXXuW001242; Thu, 22 May 2003 12:33:34 -0400 (EDT) Received: by lawyers.ir.bbn.com (Postfix, from userid 9076) id 05AAE6B2B5; Thu, 22 May 2003 12:31:03 -0400 (EDT) To: Kacheong Poon From: Mark Allman Reply-To: mallman@grc.nasa.gov Cc: tsvwg@ietf.org Subject: Re: [Tsvwg] taking NewReno (RFC 2582) to Proposed Standard In-Reply-To: <200305220619.BAA32284@parmesan.cs.wisc.edu> Organization: BBN Technologies/NASA GRC Song-of-the-Day: Mr. Jones Date: Thu, 22 May 2003 12:31:03 -0400 Message-Id: <20030522163103.05AAE6B2B5@lawyers.ir.bbn.com> Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , > Consider this case, an app using TCP has a brief moment > (much shorter than one RTT) of pause such that the number of > outstanding segments in the network is less than the current cwnd. > Should TCP reduce the cwnd because of this? I guess most, if not > all, people agree that cwnd should probably be reduced if the pause > is longer than one RTT, as described in RFC 2861. This is the idea > behind "Use-it or Lose-it." But for a period less than one RTT, I > suspect that most people will say no. > ---- > > Do most people agree with the last statement? I guess this > summarizes what I've been trying to say about maxburst. I > don't know if people on this list really want to change how > TCP works with temporary app pause. And, my point is that it doesn't matter if you use scheme (3) or scheme (1). The on-the-wire behavior is quite similar. I.e., even if you leave cwnd high you won't use it because of maxburst. So, what is the problem in dropping it if you can't use it to begin with? (The only substanitive on-the-wire difference in scheme (1) and (3) that I have seen is the one raised by Tom: that the cwnd after a loss could be different under these two schemes.) The difference in (1) and (3) comes in the actual specification and implementation. I think it is much cleaner to use scheme (3). And, I do not think we're going to agree on this point. > But it is very clear that RFC 3042 has a problem in how > the algorithm is specified. Actually, I have had a nagging feeling about this... and, my brain has just clicked. I don't think there is a problem with 3042. If there is an app pause that causes cwnd > outstanding_data (and, therefore, for the test in 3042 to look bogus) then LT will not kick in anyway because TCP is app limited and there is no new data to send. But, if outstanding_data < cwnd because of maxburst, this is not the case -- rendering the LT spec to be bogus. But, that is sort of my point -- it would be bogus because of the maxburst retrofit. > I suggest Mark to write up a paper describing his idea with data > supporting what he tries to say. I'm afraid we are just > expressing opinions here without fruitful results, except that RFC > 3042 needs some changes.... The we should also seem some study of maxburst, no? allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri May 23 13:09:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13863 for ; Fri, 23 May 2003 13:09:40 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4NH9Fq02514 for tsvwg-archive@odin.ietf.org; Fri, 23 May 2003 13:09:15 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4NH7lB01900; Fri, 23 May 2003 13:07:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4MKuLB10171 for ; Thu, 22 May 2003 16:56:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29273 for ; Thu, 22 May 2003 17:28:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IxaX-0004wm-00 for tsvwg@ietf.org; Thu, 22 May 2003 17:27:01 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 19IxaW-0004wj-00 for tsvwg@ietf.org; Thu, 22 May 2003 17:27:00 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 1C1A732993; Thu, 22 May 2003 17:28:21 -0400 (EDT) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id 5B33432992; Thu, 22 May 2003 17:28:20 -0400 (EDT) Date: Thu, 22 May 2003 17:28:20 -0400 (EDT) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: Kacheong Poon Cc: Subject: Re: [Tsvwg] taking NewReno (RFC 2582) to Proposed Standard In-Reply-To: <200305220619.BAA32284@parmesan.cs.wisc.edu> Message-ID: X-Spam-Status: No, hits=-5.0 required=6.0 tests=DEPT_RCVD,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , On Thu, 22 May 2003, Kacheong Poon wrote: > ---- > Consider this case, an app using TCP has a brief moment > (much shorter than one RTT) of pause such that the number of > outstanding segments in the network is less than the current cwnd. > Should TCP reduce the cwnd because of this? I guess most, if not > all, people agree that cwnd should probably be reduced if the pause > is longer than one RTT, as described in RFC 2861. This is the idea > behind "Use-it or Lose-it." But for a period less than one RTT, I > suspect that most people will say no. > ---- > > Do most people agree with the last statement? I think it doesn't matter how a burst is caused (e.g, application pauses, reordering, lost acks, fast recovery exited, etc)... a burst is a burst. I agree with Pasi in that if maxburst = 3, then method (1) and (3) perform equally. In that case, I prefer method (3)... which is really what we meant to specify when specifying method (2) in the SCTP implementer's guide. Method (3) becomes more conservative in comparison to method (1) as maxburst increases beyond 3. Like Mark, I prefer to not introduce another variable for limiting the sending rate, but if the acceptable maxburst is significantly larger than 3, then method (3) will hurt performance in large bandwidth-delay environments. So the questions become: 1. What is an acceptable maxburst? 2. If maxburst > 3, then can we devise a variation on method (3) that performs as well as method (1)? ~armando 0-- --0 | Armando L. Caro Jr. | Protocol Engineering Lab | | www.cis.udel.edu/~acaro | University of Delaware | 0-- --0 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri May 23 13:14:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14349 for ; Fri, 23 May 2003 13:14:22 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4NHDv603818 for tsvwg-archive@odin.ietf.org; Fri, 23 May 2003 13:13:57 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4NHCCB02938; Fri, 23 May 2003 13:12:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4NH1BB00566 for ; Fri, 23 May 2003 13:01:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13517 for ; Fri, 23 May 2003 13:01:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19JFtO-0006rE-00 for tsvwg@ietf.org; Fri, 23 May 2003 12:59:42 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 19JFtO-0006rB-00 for tsvwg@ietf.org; Fri, 23 May 2003 12:59:42 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id A5D9D32992; Fri, 23 May 2003 13:01:07 -0400 (EDT) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id DD0F6328A5; Fri, 23 May 2003 13:01:06 -0400 (EDT) Date: Fri, 23 May 2003 13:01:06 -0400 (EDT) From: "Armando L. Caro Jr." X-X-Sender: Reply-To: "Armando L. Caro Jr." To: Kacheong Poon Cc: Subject: Re: [Tsvwg] taking NewReno (RFC 2582) to Proposed Standard (fwd) Message-ID: X-Spam-Status: No, hits=-4.2 required=6.0 tests=DEPT_RCVD,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , I am resending a mail that never seemed to get through (hmmm...) ---------- Forwarded message ---------- Date: Thu, 22 May 2003 17:28:20 -0400 (EDT) From: Armando L. Caro Jr. Reply-To: Armando L. Caro Jr. To: Kacheong Poon Cc: tsvwg@ietf.org Subject: Re: [Tsvwg] taking NewReno (RFC 2582) to Proposed Standard On Thu, 22 May 2003, Kacheong Poon wrote: > ---- > Consider this case, an app using TCP has a brief moment > (much shorter than one RTT) of pause such that the number of > outstanding segments in the network is less than the current cwnd. > Should TCP reduce the cwnd because of this? I guess most, if not > all, people agree that cwnd should probably be reduced if the pause > is longer than one RTT, as described in RFC 2861. This is the idea > behind "Use-it or Lose-it." But for a period less than one RTT, I > suspect that most people will say no. > ---- > > Do most people agree with the last statement? I think it doesn't matter how a burst is caused (e.g, application pauses, reordering, lost acks, fast recovery exited, etc)... a burst is a burst. I agree with Pasi in that if maxburst = 3, then method (1) and (3) perform equally. In that case, I prefer method (3)... which is really what we meant to specify when specifying method (2) in the SCTP implementer's guide. Method (3) becomes more conservative in comparison to method (1) as maxburst increases beyond 3. Like Mark, I prefer to not introduce another variable for limiting the sending rate, but if the acceptable maxburst is significantly larger than 3, then method (3) will hurt performance in large bandwidth-delay environments. So the questions are: 1. What is an acceptable maxburst? 2. If maxburst > 3, then can we devise a variation on method (3) that performs as well as method (1)? ~armando 0-- --0 | Armando L. Caro Jr. | Protocol Engineering Lab | | www.cis.udel.edu/~acaro | University of Delaware | 0-- --0 _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri May 23 13:23:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15181 for ; Fri, 23 May 2003 13:23:38 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4NHNDJ06109 for tsvwg-archive@odin.ietf.org; Fri, 23 May 2003 13:23:13 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4NHLrB05843; Fri, 23 May 2003 13:21:53 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4N59JB06390 for ; Fri, 23 May 2003 01:09:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12824 for ; Fri, 23 May 2003 01:41:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19J5HQ-0001O1-00 for tsvwg@ietf.org; Fri, 23 May 2003 01:39:48 -0400 Received: from parmesan.cs.wisc.edu ([128.105.167.16]) by ietf-mx with esmtp (Exim 4.12) id 19J5HQ-0001Ny-00 for tsvwg@ietf.org; Fri, 23 May 2003 01:39:48 -0400 Received: (from poon@localhost) by parmesan.cs.wisc.edu (8.9.2/8.9.2) id AAA04554 for tsvwg@ietf.org; Fri, 23 May 2003 00:41:12 -0500 (CDT) Date: Fri, 23 May 2003 00:41:12 -0500 (CDT) From: Kacheong Poon Message-Id: <200305230541.AAA04554@parmesan.cs.wisc.edu> To: tsvwg@ietf.org Subject: Re: [Tsvwg] taking NewReno (RFC 2582) to Proposed Standard Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Included message from Pasi Sarolahti : >---- >But in the end, I think it is mostly an implementation issue to choose >the most suitable variant of the actual burst avoidance algorithm. As >long as the TCP congestion control RFC requires burst avoidance and >describes what is meant by burst avoidance either by using (1) or (3), >it should be ok, right? >---- It should be OK as long as they really behave similarly. But I guess scheme (3) so far has not gone through any real implementation or simulation tests. As Sally pointed out, (1) has been in NS for many many years. And it has been in use in real Internet for many many years. So I really see no ground in saying that (1) is bad based on pure opinion... Well, just my $0.02... K. Poon. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri May 23 13:32:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15659 for ; Fri, 23 May 2003 13:32:01 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4NHVbM07912 for tsvwg-archive@odin.ietf.org; Fri, 23 May 2003 13:31:37 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4NHTSB07419; Fri, 23 May 2003 13:29:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4N5quB08563 for ; Fri, 23 May 2003 01:52:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25467 for ; Fri, 23 May 2003 02:24:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19J5xd-0001jY-00 for tsvwg@ietf.org; Fri, 23 May 2003 02:23:25 -0400 Received: from parmesan.cs.wisc.edu ([128.105.167.16]) by ietf-mx with esmtp (Exim 4.12) id 19J5xc-0001jV-00 for tsvwg@ietf.org; Fri, 23 May 2003 02:23:24 -0400 Received: (from poon@localhost) by parmesan.cs.wisc.edu (8.9.2/8.9.2) id BAA04701 for tsvwg@ietf.org; Fri, 23 May 2003 01:24:49 -0500 (CDT) Date: Fri, 23 May 2003 01:24:49 -0500 (CDT) From: Kacheong Poon Message-Id: <200305230624.BAA04701@parmesan.cs.wisc.edu> To: tsvwg@ietf.org Subject: Re: [Tsvwg] taking NewReno (RFC 2582) to Proposed Standard Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Included message from Mark Allman : >---- >The difference in (1) and (3) comes in the actual specification and >implementation. I think it is much cleaner to use scheme (3). And, >I do not think we're going to agree on this point. Let's drop it then (-: >Actually, I have had a nagging feeling about this... and, my brain >has just clicked. I don't think there is a problem with 3042. If >there is an app pause that causes cwnd > outstanding_data (and, >therefore, for the test in 3042 to look bogus) then LT will not kick >in anyway because TCP is app limited and there is no new data to >send. > >But, if outstanding_data < cwnd because of maxburst, this is not the >case -- rendering the LT spec to be bogus. But, that is sort of my >point -- it would be bogus because of the maxburst retrofit. I think Mark is correct. >The we should also seem some study of maxburst, no? Since Mark is so against maxburst, I assume that he will write some papers describing its problems, as foreseen in Sally's email (-: >---- K. Poon. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Sat May 24 15:59:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04113 for ; Sat, 24 May 2003 15:59:26 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4OJx7A27793 for tsvwg-archive@odin.ietf.org; Sat, 24 May 2003 15:59:07 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4OJtqB27703; Sat, 24 May 2003 15:55:52 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4OJrnB27650 for ; Sat, 24 May 2003 15:53:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04068 for ; Sat, 24 May 2003 15:53:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Jf3q-0001pC-00 for tsvwg@ietf.org; Sat, 24 May 2003 15:52:10 -0400 Received: from web80513.mail.yahoo.com ([66.218.79.83]) by ietf-mx with smtp (Exim 4.12) id 19Jf3q-0001p8-00 for tsvwg@ietf.org; Sat, 24 May 2003 15:52:10 -0400 Message-ID: <20030524195307.77436.qmail@web80513.mail.yahoo.com> Received: from [129.15.78.34] by web80513.mail.yahoo.com via HTTP; Sat, 24 May 2003 12:53:07 PDT Date: Sat, 24 May 2003 12:53:07 -0700 (PDT) From: "Naveen.R.Ranga" To: tsvwg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Tsvwg] Socket Programming Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Hi all, This is Naveen. New to the list. Anyways I was curious in which document is it clear.. the concepts of Socket Programming of SCTP of Multistreaming and Multihoming. let me know if there are any particular examples.thanks naveen ===== NAVEEN REDDY RANGA 600, South Webster Ave,#113 Norman,OK-73069. Ph:(405)-329-5988 E-mail: Personal: rnaveenreddy@hotmail.com College:nranga@ou.edu __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Sat May 24 19:04:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08097 for ; Sat, 24 May 2003 19:04:55 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4ON4fF05601 for tsvwg-archive@odin.ietf.org; Sat, 24 May 2003 19:04:41 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4ON2VB05532; Sat, 24 May 2003 19:02:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4ON1bB05508 for ; Sat, 24 May 2003 19:01:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08022 for ; Sat, 24 May 2003 19:01:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19JhzW-0002aR-00 for tsvwg@ietf.org; Sat, 24 May 2003 18:59:54 -0400 Received: from stewart.chicago.il.us ([66.93.186.36]) by ietf-mx with esmtp (Exim 4.12) id 19JhzV-0002aI-00 for tsvwg@ietf.org; Sat, 24 May 2003 18:59:53 -0400 Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8p1/8.12.8) with ESMTP id h4ON0iqY022380; Sat, 24 May 2003 18:00:45 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3ECFF99C.7060304@stewart.chicago.il.us> Date: Sat, 24 May 2003 18:00:44 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3b) Gecko/20030323 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Naveen.R.Ranga" CC: tsvwg@ietf.org Subject: Re: [Tsvwg] Socket Programming References: <20030524195307.77436.qmail@web80513.mail.yahoo.com> In-Reply-To: <20030524195307.77436.qmail@web80513.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit You can have a look at http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-06.txt Also the upcoming edition (3rd) of Unix Network Programming Vol 1 will have about 3 chapters devoted to SCTP (available in Sept I think ... at least thats what amazon says)... Happy reading R Naveen.R.Ranga wrote: > Hi all, > This is Naveen. New to the list. Anyways I was > curious in which document is it clear.. the concepts > of Socket Programming of SCTP of Multistreaming and > Multihoming. let me know if there are any particular > examples.thanks > naveen > > ===== > NAVEEN REDDY RANGA > 600, South Webster Ave,#113 > Norman,OK-73069. > Ph:(405)-329-5988 > E-mail: > Personal: rnaveenreddy@hotmail.com > College:nranga@ou.edu > > __________________________________ > Do you Yahoo!? > The New Yahoo! Search - Faster. Easier. Bingo. > http://search.yahoo.com > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > > -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon May 26 16:29:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25754 for ; Mon, 26 May 2003 16:29:12 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4QKSss02907 for tsvwg-archive@odin.ietf.org; Mon, 26 May 2003 16:28:54 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4QKRVB02884; Mon, 26 May 2003 16:27:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4QKPjB02821 for ; Mon, 26 May 2003 16:25:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25589 for ; Mon, 26 May 2003 16:25:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KOVk-0001tl-00 for tsvwg@ietf.org; Mon, 26 May 2003 16:24:00 -0400 Received: from web80501.mail.yahoo.com ([66.218.79.71]) by ietf-mx with smtp (Exim 4.12) id 19KOVk-0001th-00 for tsvwg@ietf.org; Mon, 26 May 2003 16:24:00 -0400 Message-ID: <20030526202502.81479.qmail@web80501.mail.yahoo.com> Received: from [129.15.78.34] by web80501.mail.yahoo.com via HTTP; Mon, 26 May 2003 13:25:02 PDT Date: Mon, 26 May 2003 13:25:02 -0700 (PDT) From: "Naveen.R.Ranga" Subject: [Tsvwg] Socket Programming To: Randall Stewart Cc: tsvwg@ietf.org In-Reply-To: <3ECFF99C.7060304@stewart.chicago.il.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Hi, THanks for the reply. Actually I have this question. Do we need to have root access in order to do socket programming. Since I am trying to run the examples in the package and also a few files I had written, but they are not working. Please advise me reg this.thanks naveen ===== NAVEEN REDDY RANGA 600, South Webster Ave,#113 Norman,OK-73069. Ph:(405)-329-5988 E-mail: Personal: rnaveenreddy@hotmail.com College:nranga@ou.edu __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Mon May 26 17:45:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29028 for ; Mon, 26 May 2003 17:45:21 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4QLj6s08498 for tsvwg-archive@odin.ietf.org; Mon, 26 May 2003 17:45:06 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4QLhXB08428; Mon, 26 May 2003 17:43:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4QLgVB08355 for ; Mon, 26 May 2003 17:42:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28885 for ; Mon, 26 May 2003 17:42:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KPi1-0002tE-00 for tsvwg@ietf.org; Mon, 26 May 2003 17:40:45 -0400 Received: from stewart.chicago.il.us ([66.93.186.36]) by ietf-mx with esmtp (Exim 4.12) id 19KPi0-0002rX-00 for tsvwg@ietf.org; Mon, 26 May 2003 17:40:44 -0400 Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8p1/8.12.8) with ESMTP id h4QLfi7r009419; Mon, 26 May 2003 16:41:44 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3ED28A17.6030009@stewart.chicago.il.us> Date: Mon, 26 May 2003 16:41:43 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3b) Gecko/20030323 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Naveen.R.Ranga" CC: tsvwg@ietf.org Subject: Re: [Tsvwg] Socket Programming References: <20030526202502.81479.qmail@web80501.mail.yahoo.com> In-Reply-To: <20030526202502.81479.qmail@web80501.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Naveen.R.Ranga wrote: > Hi, > THanks for the reply. Actually I have this question. > Do we need to have root access in order to do socket > programming. Since I am trying to run the examples in > the package and also a few files I had written, but > they are not working. > Please advise me reg this.thanks > naveen > > Naveen: I am unsure what you mean by "I am trying to run the examples in the package"... what package? If your kernel supports SCTP natively... you do not need root access. Linux as the lk-sctp project and I believe versions of linux that are 2.5.xxx have a version of SCTP included. For BSD systems you need to add the KAME IP stack .. get it at http://www.kame.net After adding you must enable the option in your kernel config. options SCTP Sun has a SCTP implementation as well.. but I do not know the state of it.. it used to be something you picked up for Solaris at the sun playground site.. maybe Kachong Poon can reply and advise.. If you are attempting to use the Univ of Essen's code, I believe they DO run in user space and thus need to have a superuser ability to open a raw socket. Regards R > > ===== > NAVEEN REDDY RANGA > 600, South Webster Ave,#113 > Norman,OK-73069. > Ph:(405)-329-5988 > E-mail: > Personal: rnaveenreddy@hotmail.com > College:nranga@ou.edu > > __________________________________ > Do you Yahoo!? > The New Yahoo! Search - Faster. Easier. Bingo. > http://search.yahoo.com > > -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue May 27 14:14:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22372 for ; Tue, 27 May 2003 14:14:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4RIDeN08812 for tsvwg-archive@odin.ietf.org; Tue, 27 May 2003 14:13:40 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RIBpB08713; Tue, 27 May 2003 14:11:51 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RIA4B08676 for ; Tue, 27 May 2003 14:10:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22274 for ; Tue, 27 May 2003 14:09:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Kis5-0006q5-00 for tsvwg@ietf.org; Tue, 27 May 2003 14:08:25 -0400 Received: from stewart.chicago.il.us ([66.93.186.36]) by ietf-mx with esmtp (Exim 4.12) id 19Kis4-0006q0-00 for tsvwg@ietf.org; Tue, 27 May 2003 14:08:24 -0400 Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8p1/8.12.8) with ESMTP id h4RI9O7r015680 for ; Tue, 27 May 2003 13:09:27 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3ED3A9D4.70207@stewart.chicago.il.us> Date: Tue, 27 May 2003 13:09:24 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3b) Gecko/20030323 X-Accept-Language: en-us, en MIME-Version: 1.0 To: TSV WG list Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Tsvwg] PR SCTP Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all: A new verision of PR-SCTP is now out. It includes all comments fixes and otherwise .... I think the document is now ready for a last call someplace.. of course it is not a WG document.... so I guess it would be a IESG last call that we would ask for??? not sure... Any comments on the document would be most welcome before we proceed with it any futher.. Thanks R http://www.ietf.org/internet-drafts/draft-stewart-tsvwg-prsctp-04.txt -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue May 27 15:02:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25024 for ; Tue, 27 May 2003 15:02:41 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4RJ2Hi12581 for tsvwg-archive@odin.ietf.org; Tue, 27 May 2003 15:02:17 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RIwGB12260; Tue, 27 May 2003 14:58:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RIvUB12168 for ; Tue, 27 May 2003 14:57:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24705 for ; Tue, 27 May 2003 14:57:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Kjby-0007SL-00 for tsvwg@ietf.org; Tue, 27 May 2003 14:55:50 -0400 Received: from gw.openss7.com ([142.179.199.224] ident=[41BQUTJdwPN+/iQlcu7JMx/GvH/L5jXR]) by ietf-mx with esmtp (Exim 4.12) id 19Kjby-0007SI-00 for tsvwg@ietf.org; Tue, 27 May 2003 14:55:50 -0400 Received: from ns.pigworks.openss7.net (IDENT:cipoT7YSSJsEFW8oeUp3+7N+rVhLBfKL@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id h4RIvNF19267; Tue, 27 May 2003 12:57:23 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id h4RIvNn16726; Tue, 27 May 2003 12:57:23 -0600 Date: Tue, 27 May 2003 12:57:23 -0600 From: "Brian F. G. Bidulock" To: Randall Stewart Cc: TSV WG list Subject: Re: [Tsvwg] PR SCTP Message-ID: <20030527125723.B16536@openss7.org> Reply-To: bidulock@openss7.org References: <3ED3A9D4.70207@stewart.chicago.il.us> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3ED3A9D4.70207@stewart.chicago.il.us>; from randall@stewart.chicago.il.us on Tue, May 27, 2003 at 01:09:24PM -0500 Organization: http://www.openss7.org/ Dsn-Notification-To: X-MIME-Autoconverted: from 8bit to quoted-printable by gw.openss7.com id h4RIvNF19267 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4RIvUB12169 Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Randall, Can we not make it a WG document and proceed to WG LC on that basis? --brian On Tue, 27 May 2003, Randall Stewart wrote: > Hi all: > > A new verision of PR-SCTP is now out. It includes all > comments fixes and otherwise .... > > I think the document is now ready for a last call someplace.. of course > it is not a WG document.... so I guess it would be a IESG last > call that we would ask for??? not sure... > > Any comments on the document would be most welcome before > we proceed with it any futher.. > > Thanks > > R > > > > http://www.ietf.org/internet-drafts/draft-stewart-tsvwg-prsctp-04.txt > -- > Randall R. Stewart > randall@stewart.chicago.il.us 815-342-5222 (cell phone) > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue May 27 16:25:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00042 for ; Tue, 27 May 2003 16:25:46 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4RKPJs18523 for tsvwg-archive@odin.ietf.org; Tue, 27 May 2003 16:25:19 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RKIiB18301; Tue, 27 May 2003 16:18:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RKHHB18259 for ; Tue, 27 May 2003 16:17:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29681 for ; Tue, 27 May 2003 16:17:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KkrE-0000om-00 for tsvwg@ietf.org; Tue, 27 May 2003 16:15:40 -0400 Received: from web80505.mail.yahoo.com ([66.218.79.75]) by ietf-mx with smtp (Exim 4.12) id 19KkrD-0000oa-00 for tsvwg@ietf.org; Tue, 27 May 2003 16:15:39 -0400 Message-ID: <20030527185254.42483.qmail@web80505.mail.yahoo.com> Received: from [129.15.78.34] by web80505.mail.yahoo.com via HTTP; Tue, 27 May 2003 11:52:54 PDT Date: Tue, 27 May 2003 11:52:54 -0700 (PDT) From: "Naveen.R.Ranga" To: Randall Stewart , tsvwg@ietf.org In-Reply-To: <3ED28A17.6030009@stewart.chicago.il.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Tsvwg] Socket Programming Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Hi, I am all confused again. Let me know this. Does this package I downloaded(from www.sctp.de) and set up in my box support the draft draft-ietf-tsvwg-sctpsocket-06.txt if not where are all the system calls and the functions to be used are defined. I am unable to understand, whether there are two versions of socket programming. or the same. The socket call(is this defined here or not)... "socket(int sd, SOCK_STREAM,IPPROTO_SCTP)" will this work if I include "sctp.h" in my files. if not where could I get those. Please let me know the user library to download and install. I am running on a Red Hat Linux 9.x. I have read all of the socket api draft and I find it easy using the actual system calls. But I am unable to run the files of the sctp.de packages. Prob all the system calls defined in the draft are not used and I am confused with all this. Please let me know which package to download and do the socket programming for the SCTP(thats my goal). Please let me know soon. THanks nav --- Randall Stewart wrote: > Naveen.R.Ranga wrote: > > Hi, > > THanks for the reply. Actually I have this > question. > > Do we need to have root access in order to do > socket > > programming. Since I am trying to run the examples > in > > the package and also a few files I had written, > but > > they are not working. > > Please advise me reg this.thanks > > naveen > > > > > Naveen: > > I am unsure what you mean by "I am trying to run the > examples in the package"... what package? > > If your kernel supports SCTP natively... you do not > need root access. > > Linux as the lk-sctp project and I believe versions > of > linux that are 2.5.xxx have a version of SCTP > included. > > For BSD systems you need to add the KAME IP stack .. > get it > at > http://www.kame.net > > After adding you must enable the option in your > kernel config. > options SCTP > > > Sun has a SCTP implementation as well.. but I do not > know > the state of it.. it used to be something you picked > up for Solaris > at the sun playground site.. maybe Kachong Poon can > reply and > advise.. > > If you are attempting to use the Univ of Essen's > code, I believe > they DO run in user space and thus need to have a > superuser ability to open a raw socket. > > > Regards > > R > ===== NAVEEN REDDY RANGA 600, South Webster Ave,#113 Norman,OK-73069. Ph:(405)-329-5988 E-mail: Personal: rnaveenreddy@hotmail.com College:nranga@ou.edu __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue May 27 17:00:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02309 for ; Tue, 27 May 2003 17:00:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4RL0WP21613 for tsvwg-archive@odin.ietf.org; Tue, 27 May 2003 17:00:32 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RKxIB21197; Tue, 27 May 2003 16:59:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RKtkB21069 for ; Tue, 27 May 2003 16:55:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01946 for ; Tue, 27 May 2003 16:55:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KlST-0001PH-00 for tsvwg@ietf.org; Tue, 27 May 2003 16:54:09 -0400 Received: from stewart.chicago.il.us ([66.93.186.36]) by ietf-mx with esmtp (Exim 4.12) id 19KlSS-0001Or-00 for tsvwg@ietf.org; Tue, 27 May 2003 16:54:08 -0400 Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8p1/8.12.8) with ESMTP id h4RKtB7r016525; Tue, 27 May 2003 15:55:12 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3ED3D0AF.7040908@stewart.chicago.il.us> Date: Tue, 27 May 2003 15:55:11 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3b) Gecko/20030323 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bidulock@openss7.org CC: TSV WG list Subject: Re: [Tsvwg] PR SCTP References: <3ED3A9D4.70207@stewart.chicago.il.us> <20030527125723.B16536@openss7.org> In-Reply-To: <20030527125723.B16536@openss7.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit That would be fine with me... but Allision and Jon will have to chime in here and judge sentement etc... R Brian F. G. Bidulock wrote: > Randall, > > Can we not make it a WG document and proceed to > WG LC on that basis? > > --brian > > On Tue, 27 May 2003, Randall Stewart wrote: > > >>Hi all: >> >>A new verision of PR-SCTP is now out. It includes all >>comments fixes and otherwise .... >> >>I think the document is now ready for a last call someplace.. of course >>it is not a WG document.... so I guess it would be a IESG last >>call that we would ask for??? not sure... >> >>Any comments on the document would be most welcome before >>we proceed with it any futher.. >> >>Thanks >> >>R >> >> >> >>http://www.ietf.org/internet-drafts/draft-stewart-tsvwg-prsctp-04.txt >>-- >>Randall R. Stewart >>randall@stewart.chicago.il.us 815-342-5222 (cell phone) >> >>_______________________________________________ >>tsvwg mailing list >>tsvwg@ietf.org >>https://www1.ietf.org/mailman/listinfo/tsvwg > > -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue May 27 17:19:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02976 for ; Tue, 27 May 2003 17:19:56 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4RLJVg23803 for tsvwg-archive@odin.ietf.org; Tue, 27 May 2003 17:19:31 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RLIAB23770; Tue, 27 May 2003 17:18:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RLH4B23733 for ; Tue, 27 May 2003 17:17:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02932 for ; Tue, 27 May 2003 17:16:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Kln4-0001hn-00 for tsvwg@ietf.org; Tue, 27 May 2003 17:15:26 -0400 Received: from stewart.chicago.il.us ([66.93.186.36]) by ietf-mx with esmtp (Exim 4.12) id 19Kln3-0001hh-00 for tsvwg@ietf.org; Tue, 27 May 2003 17:15:25 -0400 Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8p1/8.12.8) with ESMTP id h4RLGJ7r016640; Tue, 27 May 2003 16:16:30 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3ED3D5A3.5000108@stewart.chicago.il.us> Date: Tue, 27 May 2003 16:16:19 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3b) Gecko/20030323 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Naveen.R.Ranga" CC: tsvwg@ietf.org References: <20030527185254.42483.qmail@web80505.mail.yahoo.com> In-Reply-To: <20030527185254.42483.qmail@web80505.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Tsvwg] Re: Socket Programming Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Naveen: This discussion really belongs on sctp-impl@external.cisco.com Not on the tsvwg.. but let me say what little I know.. You are using then a user space implementation.. My understanding of there socket implementation is you hit their library instead of the normal system lib that holds the socket api.... The folks from u of essen (Andreas) or Michael Tuexen of munester (who all belong to the sctp-impl list and have there own list as well if I remember right) would be better to answer how their socket api works... You would need to be root to run it I am sure since it must open a raw socket... If you want to get a TRUE socket api you need to either get the - KAME for BSD implementation (www.kame.net) - Lk-SCTP for linux (sourceforge I think) and I am unsure how far SUN (Kacheong?) and IBM/AIX are in their socket API .. HP has a SCTP stack too.. but I am not sure if it uses the socketapi (Jim Bound might be able to answer this)... R Naveen.R.Ranga wrote: > Hi, > I am all confused again. Let me know this. Does > this > package I downloaded(from www.sctp.de) and set up in > my box support > the > draft > draft-ietf-tsvwg-sctpsocket-06.txt > if not where are all the system calls and the > functions to be used are defined. I am unable to > understand, whether there are two versions of > socket > programming. or the same. The socket call(is this > defined here or not)... > "socket(int sd, SOCK_STREAM,IPPROTO_SCTP)" > > will this work if I include "sctp.h" in my > files. if > not where could I get those. Please let me know the > user library to download and install. I am running on > a Red Hat Linux 9.x. I have read all of the socket api > draft and I find it easy using the actual system > calls. But I am unable to run the files of the sctp.de > packages. Prob all the system calls defined in the > draft are not used and I am confused with all this. > Please let me know which package to download and do > the socket programming for the SCTP(thats my goal). > Please > let me know soon. THanks > > nav > > > > > --- Randall Stewart > wrote: > >>Naveen.R.Ranga wrote: >> >>>Hi, >>>THanks for the reply. Actually I have this >> >>question. >> >>>Do we need to have root access in order to do >> >>socket >> >>>programming. Since I am trying to run the examples >> >>in >> >>>the package and also a few files I had written, >> >>but >> >>>they are not working. >>>Please advise me reg this.thanks >>>naveen >>> >>> >> >>Naveen: >> >>I am unsure what you mean by "I am trying to run the >>examples in the package"... what package? >> >>If your kernel supports SCTP natively... you do not >>need root access. >> >>Linux as the lk-sctp project and I believe versions >>of >>linux that are 2.5.xxx have a version of SCTP >>included. >> >>For BSD systems you need to add the KAME IP stack .. >>get it >>at >>http://www.kame.net >> >>After adding you must enable the option in your >>kernel config. >>options SCTP >> >> >>Sun has a SCTP implementation as well.. but I do not >>know >>the state of it.. it used to be something you picked >>up for Solaris >>at the sun playground site.. maybe Kachong Poon can >>reply and >>advise.. >> >>If you are attempting to use the Univ of Essen's >>code, I believe >>they DO run in user space and thus need to have a >>superuser ability to open a raw socket. >> >> >>Regards >> >>R >> > > > ===== > NAVEEN REDDY RANGA > 600, South Webster Ave,#113 > Norman,OK-73069. > Ph:(405)-329-5988 > E-mail: > Personal: rnaveenreddy@hotmail.com > College:nranga@ou.edu > > __________________________________ > Do you Yahoo!? > The New Yahoo! Search - Faster. Easier. Bingo. > http://search.yahoo.com > > -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue May 27 17:27:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03179 for ; Tue, 27 May 2003 17:27:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4RLQex24015 for tsvwg-archive@odin.ietf.org; Tue, 27 May 2003 17:26:40 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RLOTB23946; Tue, 27 May 2003 17:24:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RLNJB23895 for ; Tue, 27 May 2003 17:23:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03075 for ; Tue, 27 May 2003 17:23:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Klt7-0001jQ-00 for tsvwg@ietf.org; Tue, 27 May 2003 17:21:41 -0400 Received: from joda.cis.temple.edu ([155.247.71.60] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19Klt6-0001jN-00 for tsvwg@ietf.org; Tue, 27 May 2003 17:21:40 -0400 Received: from BLUEHEN.acm.org (bluehen.cis.temple.edu [155.247.182.8]) by joda.cis.temple.edu (8.9.3/8.9.3) with ESMTP id RAA14269; Tue, 27 May 2003 17:23:12 -0400 (EDT) Message-Id: <5.1.0.14.2.20030527171911.02565e70@joda.cis.temple.edu> X-Sender: conrad@joda.cis.temple.edu X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 27 May 2003 17:29:30 -0400 To: "Naveen.R.Ranga" , Randall Stewart , tsvwg@ietf.org From: "Phillip T. Conrad" Subject: Re: [Tsvwg] Socket Programming In-Reply-To: <20030527185254.42483.qmail@web80505.mail.yahoo.com> References: <3ED28A17.6030009@stewart.chicago.il.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Naveen, You are addressing your questions to the wrong mailing list. The support list for the www.sctp.de implementation is at http://www.sctp.de/mailman/listinfo/discussion . This mailing list (tsvwg@ietf.org) is for general discussion of transport layer design issues. So if you want to suggest changes to draft-ietf-tsvwg-sctpsocket-06.txt , or want to ask questions about the design issues involved in the draft, you may do so here. But if you want to know how to use the www.sctp.de implementation (or any other specific implementation) you should address your question to a software support list for that implementation. Best Regards, Phill Conrad At 11:52 AM 5/27/2003 -0700, Naveen.R.Ranga wrote: >Hi, > I am all confused again. Let me know this. Does >this >package I downloaded(from www.sctp.de) and set up in >my box support >the >draft > draft-ietf-tsvwg-sctpsocket-06.txt >if not where are all the system calls and the >functions to be used are defined. I am unable to >understand, whether there are two versions of >socket >programming. or the same. The socket call(is this >defined here or not)... >"socket(int sd, SOCK_STREAM,IPPROTO_SCTP)" > _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Tue May 27 17:47:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03896 for ; Tue, 27 May 2003 17:47:31 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4RLl7E25888 for tsvwg-archive@odin.ietf.org; Tue, 27 May 2003 17:47:07 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RLh7B25723; Tue, 27 May 2003 17:43:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RLeEB25618 for ; Tue, 27 May 2003 17:40:14 -0400 Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03734 for ; Tue, 27 May 2003 17:40:08 -0400 (EDT) Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h4RLZ932023166 for ; Tue, 27 May 2003 14:35:09 -0700 (MST) Received: from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id h4RLZ7ax026672 for ; Tue, 27 May 2003 16:35:07 -0500 Received: from motorola.com (d1421-0a1070d5.cig.mot.com [10.16.112.213]) by il27exb01.cig.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id KK95PYAM; Tue, 27 May 2003 16:35:07 -0500 Message-ID: <3ED3DAFB.EAA06C8E@motorola.com> Date: Tue, 27 May 2003 16:39:07 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Naveen.R.Ranga" CC: Randall Stewart , tsvwg@ietf.org Subject: Re: [Tsvwg] Socket Programming References: <20030527185254.42483.qmail@web80505.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Nav, One thing to keep in mind is that the socket API draft (as well as the RFC in the end) is NOT an IETF mandatory standards. Therefore, each individual implementation will likely take the liberty to set its own degree of compliance to the API. You need to read the release note(s) of the implementation you are investigating very closely to understand what API calls are and are not supported. -Qiaobing "Naveen.R.Ranga" wrote: > > Hi, > I am all confused again. Let me know this. Does > this > package I downloaded(from www.sctp.de) and set up in > my box support > the > draft > draft-ietf-tsvwg-sctpsocket-06.txt > if not where are all the system calls and the > functions to be used are defined. I am unable to > understand, whether there are two versions of > socket > programming. or the same. The socket call(is this > defined here or not)... > "socket(int sd, SOCK_STREAM,IPPROTO_SCTP)" > > will this work if I include "sctp.h" in my > files. if > not where could I get those. Please let me know the > user library to download and install. I am running on > a Red Hat Linux 9.x. I have read all of the socket api > draft and I find it easy using the actual system > calls. But I am unable to run the files of the sctp.de > packages. Prob all the system calls defined in the > draft are not used and I am confused with all this. > Please let me know which package to download and do > the socket programming for the SCTP(thats my goal). > Please > let me know soon. THanks > > nav > > --- Randall Stewart > wrote: > > Naveen.R.Ranga wrote: > > > Hi, > > > THanks for the reply. Actually I have this > > question. > > > Do we need to have root access in order to do > > socket > > > programming. Since I am trying to run the examples > > in > > > the package and also a few files I had written, > > but > > > they are not working. > > > Please advise me reg this.thanks > > > naveen > > > > > > > > Naveen: > > > > I am unsure what you mean by "I am trying to run the > > examples in the package"... what package? > > > > If your kernel supports SCTP natively... you do not > > need root access. > > > > Linux as the lk-sctp project and I believe versions > > of > > linux that are 2.5.xxx have a version of SCTP > > included. > > > > For BSD systems you need to add the KAME IP stack .. > > get it > > at > > http://www.kame.net > > > > After adding you must enable the option in your > > kernel config. > > options SCTP > > > > > > Sun has a SCTP implementation as well.. but I do not > > know > > the state of it.. it used to be something you picked > > up for Solaris > > at the sun playground site.. maybe Kachong Poon can > > reply and > > advise.. > > > > If you are attempting to use the Univ of Essen's > > code, I believe > > they DO run in user space and thus need to have a > > superuser ability to open a raw socket. > > > > > > Regards > > > > R > > > > ===== > NAVEEN REDDY RANGA > 600, South Webster Ave,#113 > Norman,OK-73069. > Ph:(405)-329-5988 > E-mail: > Personal: rnaveenreddy@hotmail.com > College:nranga@ou.edu > > __________________________________ > Do you Yahoo!? > The New Yahoo! Search - Faster. Easier. Bingo. > http://search.yahoo.com > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Thu May 29 20:26:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29459 for ; Thu, 29 May 2003 20:26:24 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4U0PvP03456 for tsvwg-archive@odin.ietf.org; Thu, 29 May 2003 20:25:57 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4U0OLB03279; Thu, 29 May 2003 20:24:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4U0HLB02920 for ; Thu, 29 May 2003 20:17:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28909 for ; Thu, 29 May 2003 20:17:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LXYa-0004fM-00 for tsvwg@ietf.org; Thu, 29 May 2003 20:15:40 -0400 Received: from mx-out.daemonmail.net ([216.104.160.39]) by ietf-mx with esmtp (Exim 4.12) id 19LXYZ-0004fJ-00 for tsvwg@ietf.org; Thu, 29 May 2003 20:15:39 -0400 Received: from mx0.emailqueue.net (localhost.daemonmail.net [127.0.0.1]) by mx-out.daemonmail.net (8.9.3p2/8.9.3) with SMTP id RAA79320 for ; Thu, 29 May 2003 17:17:20 -0700 (PDT) (envelope-from spencer@mcsr-labs.org) Received: from (12.237.229.250 [12.237.229.250]) by mail.varaha.com with SMTP id lcK0HhQ2 Thu, 29 May 2003 17:17:19 -0700 (PDT) Message-ID: <025c01c32640$d3e4b750$0200a8c0@DFNJGL21> Reply-To: "Spencer Dawkins" From: "Spencer Dawkins" To: "TSVWG Mailing List" Date: Thu, 29 May 2003 19:17:16 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Subject: [Tsvwg] TRIGTRAN LinkUp first draft available Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit If you have questions or comments about the Link Up Notification draft announced yesterday, I'd LOVE to hear them. Please follow up on the TRIGTRAN Mailing List - the coordinates are as follows: General Discussion: trigtran@ietf.org To Subscribe: trigtran-request@ietf.org In Body: subscribe Archives: www.ietf.org/mail-archive/working-groups/trigtran/current/maillist.html Announcement available at: http://www1.ietf.org/mail-archive/ietf-announce/Current/msg24268.html Thanks! Spencer Dawkins _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Fri May 30 15:19:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23862 for ; Fri, 30 May 2003 15:19:24 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4UJIt830044 for tsvwg-archive@odin.ietf.org; Fri, 30 May 2003 15:18:55 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UJHRB29952; Fri, 30 May 2003 15:17:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UJGNB29896 for ; Fri, 30 May 2003 15:16:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23690 for ; Fri, 30 May 2003 15:16:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LpKr-0000Lg-00 for tsvwg@ietf.org; Fri, 30 May 2003 15:14:41 -0400 Received: from defender.ccpu.com ([216.54.134.34] helo=smtp.ccpu.com) by ietf-mx with esmtp (Exim 4.12) id 19LpKr-0000Ld-00 for tsvwg@ietf.org; Fri, 30 May 2003 15:14:41 -0400 Received: from [172.16.1.40] (helo=ccpu00251) by smtp.ccpu.com with smtp (Exim 4.20 #1 (Debian)) id 19LpMT-0004y8-4H for ; Fri, 30 May 2003 12:16:21 -0700 Reply-To: From: "Umesh Vats" To: Date: Fri, 30 May 2003 12:19:13 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [Tsvwg] A query Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Can an SCTP endpoint use different set of source address for different associations origination/terminating on it ? E.g, suppose an endpoint (ASP/SGP/IPSP) has source(self) IP addresses A, B, C, D, E, F and G. Can this endpoint assign source addresses to three associations as : Assoc 1 : A, B, C Assoc 2 : C, D, E Assoc 3 : F, G Umesh Vats _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Sat May 31 20:03:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14150 for ; Sat, 31 May 2003 20:03:52 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5103N617973 for tsvwg-archive@odin.ietf.org; Sat, 31 May 2003 20:03:23 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h51026B17947; Sat, 31 May 2003 20:02:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h51008B17872 for ; Sat, 31 May 2003 20:00:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14125 for ; Sat, 31 May 2003 20:00:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MGEx-0002BN-00 for tsvwg@ietf.org; Sat, 31 May 2003 19:58:23 -0400 Received: from stewart.chicago.il.us ([66.93.186.36]) by ietf-mx with esmtp (Exim 4.12) id 19MGEw-0002B7-00 for tsvwg@ietf.org; Sat, 31 May 2003 19:58:22 -0400 Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8p1/8.12.8) with ESMTP id h4VNwu7r050495; Sat, 31 May 2003 18:58:57 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3ED941C0.3040106@stewart.chicago.il.us> Date: Sat, 31 May 2003 18:58:56 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3b) Gecko/20030323 X-Accept-Language: en-us, en MIME-Version: 1.0 To: umesh@ccpu.com CC: tsvwg@ietf.org Subject: Re: [Tsvwg] A query References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Umesh Vats wrote: > Can an SCTP endpoint use different set of source address for different > associations > origination/terminating on it ? E.g, suppose an endpoint (ASP/SGP/IPSP) has > source(self) > IP addresses A, B, C, D, E, F and G. > > Can this endpoint assign source addresses to three associations as : > Assoc 1 : A, B, C > Assoc 2 : C, D, E > Assoc 3 : F, G > > Umesh Vats > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > https://www1.ietf.org/mailman/listinfo/tsvwg > > Hmm... Yes, I think this could be done.. as long as the stack can handle it and not confuse the packets.. If I wanted to do this with the sockets api on the KAME-FreeBSD machine it would have to be three sockets One would do bind(a) sctp_bindx(b,c) the second bind(c) sctp_bindx(d,e) and the third bind(f) sctp_bindx(g) I am assuming here you are talking about the same port number on all of them. In the above (for kame) you would actually have 3 endpoints... But one could open them in the same program if one wanted.. R -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From mailnull@www1.ietf.org Sat May 31 23:35:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17857 for ; Sat, 31 May 2003 23:35:29 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h513Z2q29232 for tsvwg-archive@odin.ietf.org; Sat, 31 May 2003 23:35:02 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h513XeB29204; Sat, 31 May 2003 23:33:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h513WCB29164 for ; Sat, 31 May 2003 23:32:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17818 for ; Sat, 31 May 2003 23:32:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MJYB-0003EH-00 for tsvwg@ietf.org; Sat, 31 May 2003 23:30:27 -0400 Received: from thebe.your-site.com ([140.186.45.26]) by ietf-mx with esmtp (Exim 4.12) id 19MJYB-0003E2-00 for tsvwg@ietf.org; Sat, 31 May 2003 23:30:27 -0400 Received: from 192.168.0.216 (208-41-143-203.client.dsl.net [208.41.143.203]) by thebe.your-site.com (Postfix) with ESMTP id 95F6B24572B; Sat, 31 May 2003 23:32:07 -0400 (EDT) Date: Sat, 31 May 2003 22:31:37 -0500 From: Caitlin Bestler Subject: Re: [Tsvwg] A query To: Randall Stewart Cc: umesh@ccpu.com, tsvwg@ietf.org X-Priority: 3 In-Reply-To: <3ED941C0.3040106@stewart.chicago.il.us> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; Charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 1.5.3 (Blindsider) Content-Transfer-Encoding: 7bit Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Umesh Vats wrote: > > Can an SCTP endpoint use different set of source address for different > > associations > > origination/terminating on it ? E.g, suppose an endpoint > (ASP/SGP/IPSP) has > > source(self) > > IP addresses A, B, C, D, E, F and G. > > > > Can this endpoint assign source addresses to three associations as : > > Assoc 1 : A, B, C > > Assoc 2 : C, D, E > > Assoc 3 : F, G > > > > Umesh Vats > > In addition to whatever limitations the local stack may have, you have to consider how things would look to the remote end if multiple of these endpoints attempted to connected to the same remote endpoint. If Assoc 1 and Assoc 2 had the same port number, I believe there would be problems attempting to form an association with the same remote endpoint. It would appear that the host that included C was trying to change its list of IP addresses. While the remote host would never realize that Assoc 1 and Assoc 3 were the same machine. Ditto for Assoc 2 and Assoc 3. _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg