From lisongxu2 at gmail.com Tue Mar 15 15:36:33 2011 From: lisongxu2 at gmail.com (Lisong Xu) Date: Tue, 15 Mar 2011 17:36:33 -0500 Subject: [e2e] Identifying TCP congestion control algorithms, and measurement results Message-ID: Greetings, We have recently developed a tool, called TCP Congestion Control Avoidance Identification (CAAI), for actively identifying the TCP congestion avoidance algorithm of a remote web server. We used CAAI to measure the TCP algorithms of the top 5000 web sites in February 2011, and got some preliminary results in which you might be interested. # Only 16.85~25.58% of web servers still use the traditional AIMD. # 14.36%, 15.82%, and 14.33% of web servers use BIC, CUBIC' (kernel 2.6.25 and before), and CUBIC (kernel 2.6.26 and after), respectively. Total = 44.51%. # 9.97% and 0.30~9.03% of web servers use CTCP' (Windows Server 2003 and XP Pro x64) and CTCP (Windows Server 2008, Vista, and 7), respectively. Interestingly, CTCP' behaves very similar to HSTCP. Total = 10.27~19%. # Some web servers use non-default TCP algorithms (such as YEAH), some web servers use some unknown TCP algorithms which are not available in any major operating system family, and some web servers use abnormal slow start algorithms. More information is available at our project webpage http://cse.unl.edu/~xu/research/TCPcensus.html. Thanks Lisong -- Lisong Xu, Associate Professor Computer Science & Engineering University of Nebraska-Lincoln http://cse.unl.edu/~xu From michawe at ifi.uio.no Mon Mar 21 03:21:17 2011 From: michawe at ifi.uio.no (michawe) Date: Mon, 21 Mar 2011 11:21:17 +0100 Subject: [e2e] Looking for measurements on UDP blocking and rate limiting Message-ID: <9E2F5915-CA09-4048-A298-07B2BEC860BC@ifi.uio.no> Hi, I just spent quite a long time searching, including digging through the last couple of years of IMC, PAM and SIGMETRICS - but to my surprise, I was unable to find any measurement study on UDP blocking or UDP-specific (as opposed to TCP-) rate limiting in the Internet. There must be some studies out there?! Any hints would be greatly appreciated; and very sorry for the noise in case I just overlooked a very obvious and well-known reference! Michael From partha at cc.gatech.edu Mon Mar 21 21:57:43 2011 From: partha at cc.gatech.edu (Partha Kanuparthy) Date: Tue, 22 Mar 2011 00:57:43 -0400 Subject: [e2e] Looking for measurements on UDP blocking and rate limiting In-Reply-To: <9E2F5915-CA09-4048-A298-07B2BEC860BC@ifi.uio.no> References: <9E2F5915-CA09-4048-A298-07B2BEC860BC@ifi.uio.no> Message-ID: <4D882C47.6010209@cc.gatech.edu> Hi Michael, This is in response to your question on UDP rate limiting. We have been working on a tool called ShaperProbe to detect traffic shaping signatures on UDP traffic, and to estimate the corresponding token bucket parameters. We host it as a service on M-Lab; please feel free to test it: http://www.measurementlab.net/measurement-lab-tools#tool5 We have collected shaping data from several ISPs over the last couple of months. A tech report describing a few ISP observations is online: http://www.cc.gatech.edu/~partha/shaperprobe-TR.pdf Thanks, Partha. michawe wrote: > Hi, > > I just spent quite a long time searching, including digging through the last couple of years of IMC, PAM and SIGMETRICS - but to my surprise, I was unable to find any measurement study on UDP blocking or UDP-specific (as opposed to TCP-) rate limiting in the Internet. There must be some studies out there?! > > Any hints would be greatly appreciated; and very sorry for the noise in case I just overlooked a very obvious and well-known reference! > Michael > > From michawe at ifi.uio.no Tue Mar 22 05:38:52 2011 From: michawe at ifi.uio.no (michawe) Date: Tue, 22 Mar 2011 13:38:52 +0100 Subject: [e2e] Looking for measurements on UDP blocking and rate limiting In-Reply-To: <4D882C47.6010209@cc.gatech.edu> References: <9E2F5915-CA09-4048-A298-07B2BEC860BC@ifi.uio.no> <4D882C47.6010209@cc.gatech.edu> Message-ID: <6C010139-75C4-4E18-8D63-E18EBDE44650@ifi.uio.no> Thanks a lot, that's interesting! but I should have been clearer in what I need: the difference between the rate achievable by TCP and UDP. (i.e. I care about TCP vs. UDP, and I don't care about the actual method of rate limitation, shaping or policing). >From your TR, it seems that I can get an idea by comparing figures 9 and 14, which roughly indicates that Cox probably doesn't differentiate between UDP and TCP for shaping; but these two experiment types are probably not correlated... Anyway, thanks again for this! Cheers, Michael On Mar 22, 2011, at 5:57 AM, Partha Kanuparthy wrote: > Hi Michael, > > This is in response to your question on UDP rate limiting. We have been working on a tool called ShaperProbe to detect traffic shaping signatures on UDP traffic, and to estimate the corresponding token bucket parameters. We host it as a service on M-Lab; please feel free to test it: > http://www.measurementlab.net/measurement-lab-tools#tool5 > > We have collected shaping data from several ISPs over the last couple of months. A tech report describing a few ISP observations is online: > http://www.cc.gatech.edu/~partha/shaperprobe-TR.pdf > > Thanks, > Partha. > > > michawe wrote: >> Hi, >> I just spent quite a long time searching, including digging through the last couple of years of IMC, PAM and SIGMETRICS - but to my surprise, I was unable to find any measurement study on UDP blocking or UDP-specific (as opposed to TCP-) rate limiting in the Internet. There must be some studies out there?! >> Any hints would be greatly appreciated; and very sorry for the noise in case I just overlooked a very obvious and well-known reference! >> Michael > From ka-cheong.poon at oracle.com Thu Mar 24 00:52:15 2011 From: ka-cheong.poon at oracle.com (Kacheong Poon) Date: Thu, 24 Mar 2011 15:52:15 +0800 Subject: [e2e] TCP sequence number reset Message-ID: <4D8AF82F.8060100@oracle.com> Just want to get some opinion from the list members about an idea proposed in an IETF draft. The equivalent idea when applied to TCP is sequence number reset. The idea is that assuming an application can access TCP sequence number with each byte of data, an app is allowed to reset the TCP sequence number when it wants to. The sequence number is set to a number not acceptable (add 231) in the current connection. Note that there is no clear usage proposed in that draft nor any reason that it is needed, just a mechanism to do it. I want to see whether folks on this list think that it is a good or bad idea? And why? Thanks. -- K. Poon. ka-cheong.poon at oracle.com From eric.brown at vt.edu Thu Mar 24 06:38:49 2011 From: eric.brown at vt.edu (Eric Brown) Date: Thu, 24 Mar 2011 09:38:49 -0400 Subject: [e2e] TCP sequence number reset In-Reply-To: <4D8AF82F.8060100@oracle.com> References: <4D8AF82F.8060100@oracle.com> Message-ID: <20110324133849.GC19194@locust.cns.vt.edu> Whether the idea proposed in the draft you are referencing truly has an analogue in TCP may or may not be true. You haven't included a reference. That being said, I'd consider this to be a bad thing with respect to TCP. First and foremost TCP is a distributed state machine, that is how it is able to achieve reliable and ordered delivery of data in even the most hostile of conditions. A necessary component of a distributed state machine is a virtual clock. Sequence numbers are TCP's virtual clock ensuring that the FSM progresses in order. In the very least it would be difficult to understand all the consequences of overloading more semantics on the progression of the sequence space. --Eric Brown, Virginia Tech On Thu, Mar 24, 2011 at 03:52:15PM +0800, Kacheong Poon wrote: > Just want to get some opinion from the list members about an > idea proposed in an IETF draft. The equivalent idea when > applied to TCP is sequence number reset. The idea is that > assuming an application can access TCP sequence number with > each byte of data, an app is allowed to reset the TCP sequence > number when it wants to. The sequence number is set to a number > not acceptable (add 231) in the current connection. Note that > there is no clear usage proposed in that draft nor any reason > that it is needed, just a mechanism to do it. I want to see > whether folks on this list think that it is a good or bad idea? > And why? > > Thanks. > > > -- > > K. Poon. > ka-cheong.poon at oracle.com From perfgeek at mac.com Thu Mar 24 07:22:21 2011 From: perfgeek at mac.com (rick jones) Date: Thu, 24 Mar 2011 07:22:21 -0700 Subject: [e2e] TCP sequence number reset In-Reply-To: <4D8AF82F.8060100@oracle.com> References: <4D8AF82F.8060100@oracle.com> Message-ID: <17CA5EAC-0DD4-4813-96A9-C4A9503C6D27@mac.com> On Mar 24, 2011, at 12:52 AM, Kacheong Poon wrote: > Just want to get some opinion from the list members about an > idea proposed in an IETF draft. The equivalent idea when > applied to TCP is sequence number reset. The idea is that > assuming an application can access TCP sequence number with > each byte of data, an app is allowed to reset the TCP sequence > number when it wants to. The sequence number is set to a number > not acceptable (add 231) in the current connection. Note that > there is no clear usage proposed in that draft nor any reason > that it is needed, just a mechanism to do it. I want to see > whether folks on this list think that it is a good or bad idea? > And why? The sequence number is a rather fundamental part of TCP's correctness mechanisms. For an application to futz with it, well, is just wrong. Particularly if there is no usage of/reason for its being presented. Too much rope. rick jones http://homepage.mac.com/perfgeek From ka-cheong.poon at oracle.com Thu Mar 24 09:48:50 2011 From: ka-cheong.poon at oracle.com (Kacheong Poon) Date: Fri, 25 Mar 2011 00:48:50 +0800 Subject: [e2e] TCP sequence number reset In-Reply-To: <20110324133849.GC19194@locust.cns.vt.edu> References: <4D8AF82F.8060100@oracle.com> <20110324133849.GC19194@locust.cns.vt.edu> Message-ID: <4D8B75F2.2080107@oracle.com> On 03/24/11 09:38 PM, Eric Brown wrote: > Whether the idea proposed in the draft you are referencing truly > has an analogue in TCP may or may not be true. You haven't included > a reference. That being said, I'd consider this to be a bad thing with > respect to TCP. First and foremost TCP is a distributed state machine, > that is how it is able to achieve reliable and ordered delivery of > data in even the most hostile of conditions. A necessary component of > a distributed state machine is a virtual clock. Sequence numbers are > TCP's virtual clock ensuring that the FSM progresses in order. In the > very least it would be difficult to understand all the consequences of > overloading more semantics on the progression of the sequence space. The draft is draft-ietf-tsvwg-sctp-strrst-09.txt and I think the analogy to TCP is accurate. -- K. Poon. ka-cheong.poon at oracle.com From sgros at zemris.fer.hr Thu Mar 24 13:45:28 2011 From: sgros at zemris.fer.hr (Stjepan Gros) Date: Thu, 24 Mar 2011 21:45:28 +0100 Subject: [e2e] TCP sequence number reset In-Reply-To: <4D8AF82F.8060100@oracle.com> References: <4D8AF82F.8060100@oracle.com> Message-ID: <1300999528.4347.11.camel@w500.sistemnet.local> On Thu, 2011-03-24 at 15:52 +0800, Kacheong Poon wrote: > Just want to get some opinion from the list members about an > idea proposed in an IETF draft. The equivalent idea when > applied to TCP is sequence number reset. The idea is that > assuming an application can access TCP sequence number with > each byte of data, an app is allowed to reset the TCP sequence > number when it wants to. The sequence number is set to a number > not acceptable (add 231) in the current connection. Note that > there is no clear usage proposed in that draft nor any reason > that it is needed, just a mechanism to do it. I want to see > whether folks on this list think that it is a good or bad idea? > And why? I'll start with the question why should an application know/care about sequence numbers of transport layer? No matter how hard I tried to think of a reason for letting application know that I couldn't think of any. If any application needs this functionality it can count those units for itself (or prepend sequence numbers before sending data). Only information currently unavailable to an application are sequence numbers in flight, but again, of what use is that? In other words, sequence numbers have certain meaning to the transport layer, and now this mechanism would allow applications to add their own semantic on top of it and make things even more complex. So let me try to summarize objections/comments valid for, at least, TCP: A. There is no point in introducing any mechanism into any protocol without a proper justification/motivation of what benefit it would bring. Otherwise, it's only purpose is to increase protocol's complexity (that of implemented protocol and/or in the number of protocol specifications). Of course, this is a valid reason only in the case when there is intent to "standardize" mechanism (in RFC to be more precise). B. Sequence numbers are internal mechanism to TCP. Allowing them to be visible to applications would introduce tight coupling between TCP's protocol machine and user applications. This would, IMHO, be analogous (though not the same) to the situation we currently have with IP addresses visible in the higher layers. C. Impact of the application having the ability to mess with sequence nmbers (and as the consequence with the window and congestion windows) and acknowledge mechanism shouldn't be taken so lightly. I think more analysis and studying potential consequences would be necessary. These are high level objections and for me the reason A is number one blocker. To get low level objections you should be more precise in the description of the mechanism. This would allow protocol analysis that could reveal potential illegal protocol states or possible protocol malfunctioning. My $0.02 Stjepan Gros From touch at isi.edu Thu Mar 24 15:47:11 2011 From: touch at isi.edu (Joe Touch) Date: Thu, 24 Mar 2011 15:47:11 -0700 Subject: [e2e] TCP sequence number reset In-Reply-To: <4D8B75F2.2080107@oracle.com> References: <4D8AF82F.8060100@oracle.com> <20110324133849.GC19194@locust.cns.vt.edu> <4D8B75F2.2080107@oracle.com> Message-ID: <4D8BC9EF.4060207@isi.edu> On 3/24/2011 9:48 AM, Kacheong Poon wrote: > On 03/24/11 09:38 PM, Eric Brown wrote: >> Whether the idea proposed in the draft you are referencing truly >> has an analogue in TCP may or may not be true. You haven't included >> a reference. That being said, I'd consider this to be a bad thing with >> respect to TCP. First and foremost TCP is a distributed state machine, >> that is how it is able to achieve reliable and ordered delivery of >> data in even the most hostile of conditions. A necessary component of >> a distributed state machine is a virtual clock. Sequence numbers are >> TCP's virtual clock ensuring that the FSM progresses in order. In the >> very least it would be difficult to understand all the consequences of >> overloading more semantics on the progression of the sequence space. > > > The draft is draft-ietf-tsvwg-sctp-strrst-09.txt and I think > the analogy to TCP is accurate. SCTP includes the idea of individual streams, and the value of the sequence number has a meaning within a stream. In the above draft, it's used to allow a stream to be reused within an E2E association. In TCP, the sequence number only has meaning to the reliability of the stream; there's only one E2E association. Resetting the number has no semantic value within the stream. There is no way to establish that TCP has no outstanding data, and so *can* reset the stream, other than via a FIN (which would close the connection). Applications in TCP never see or know the sequence number. All they know is the byte stream they are presented with. Finally, this has nothing to do with virtual clock; the FSM of TCP has independent components - one having to do with the sequence number, and another having to do with the state machine. They interact only in a very few cases. The virtual clock is how TCP ends up pacing the outputs, in a very loose sense (e.g., ACK compression interferes with it, as do cumulative ACKs and reordering, etc.) Overall, I don't see *why* anyone would want to reset TCP's seqnum. TCP options are sent unreliably and out of order, and generally aren't bidirectionally stateful EXCEPT during the SYN handshake. Just doing the reset would be hard enough, and it would probably require just as much effort (if not more) and delay as setting up a new connection - i.e., lots of pain with little benefit. Joe From ka-cheong.poon at oracle.com Thu Mar 24 22:02:04 2011 From: ka-cheong.poon at oracle.com (Kacheong Poon) Date: Fri, 25 Mar 2011 13:02:04 +0800 Subject: [e2e] TCP sequence number reset In-Reply-To: <4D8BC9EF.4060207@isi.edu> References: <4D8AF82F.8060100@oracle.com> <20110324133849.GC19194@locust.cns.vt.edu> <4D8B75F2.2080107@oracle.com> <4D8BC9EF.4060207@isi.edu> Message-ID: <4D8C21CC.9090608@oracle.com> On 03/25/11 06:47 AM, Joe Touch wrote: >> The draft is draft-ietf-tsvwg-sctp-strrst-09.txt and I think >> the analogy to TCP is accurate. > > SCTP includes the idea of individual streams, and the value of the > sequence number has a meaning within a stream. In the above draft, it's > used to allow a stream to be reused within an E2E association. If you check the draft carefully, it proposes a mechanism to reset the transmission sequence number (TSN) of an association. This is equivalent to resetting TCP sequence number. The stream sequence number (SSN) is per stream but TSN is per association. -- K. Poon. ka-cheong.poon at oracle.com From touch at isi.edu Thu Mar 24 22:15:16 2011 From: touch at isi.edu (Joe Touch) Date: Thu, 24 Mar 2011 22:15:16 -0700 Subject: [e2e] TCP sequence number reset In-Reply-To: <4D8C21CC.9090608@oracle.com> References: <4D8AF82F.8060100@oracle.com> <20110324133849.GC19194@locust.cns.vt.edu> <4D8B75F2.2080107@oracle.com> <4D8BC9EF.4060207@isi.edu> <4D8C21CC.9090608@oracle.com> Message-ID: <4D8C24E4.6060401@isi.edu> On 3/24/2011 10:02 PM, Kacheong Poon wrote: > On 03/25/11 06:47 AM, Joe Touch wrote: > >>> The draft is draft-ietf-tsvwg-sctp-strrst-09.txt and I think >>> the analogy to TCP is accurate. >> >> SCTP includes the idea of individual streams, and the value of the >> sequence number has a meaning within a stream. In the above draft, it's >> used to allow a stream to be reused within an E2E association. > > If you check the draft carefully, it proposes a mechanism to reset > the transmission sequence number (TSN) of an association. This > is equivalent to resetting TCP sequence number. The stream > sequence number (SSN) is per stream but TSN is per association. The SCTP TSN is similar to TCP's sequence number, but due to the relationship to the SSNs they're not directly related. Resetting the TSN appears to be useful only in relation to resetting all the SSNs at once, since they are based on the TSN. The document lacks any direct rationale for TSN reset other than this, which is implied (this should be explicitly addressed, IMO). There's no notion of separate streams in TCP, so there's no purpose in resetting TCP's sequence number, thus the analogy doesn't hold. Joe From ka-cheong.poon at oracle.com Thu Mar 24 23:14:31 2011 From: ka-cheong.poon at oracle.com (Kacheong Poon) Date: Fri, 25 Mar 2011 14:14:31 +0800 Subject: [e2e] TCP sequence number reset In-Reply-To: <4D8C24E4.6060401@isi.edu> References: <4D8AF82F.8060100@oracle.com> <20110324133849.GC19194@locust.cns.vt.edu> <4D8B75F2.2080107@oracle.com> <4D8BC9EF.4060207@isi.edu> <4D8C21CC.9090608@oracle.com> <4D8C24E4.6060401@isi.edu> Message-ID: <4D8C32C7.8060904@oracle.com> On 03/25/11 01:15 PM, Joe Touch wrote: > The SCTP TSN is similar to TCP's sequence number, but due to the > relationship to the SSNs they're not directly related. Resetting the TSN > appears to be useful only in relation to resetting all the SSNs at once, > since they are based on the TSN. The document lacks any direct rationale > for TSN reset other than this, which is implied (this should be > explicitly addressed, IMO). > > There's no notion of separate streams in TCP, so there's no purpose in > resetting TCP's sequence number, thus the analogy doesn't hold. What is your reason that a TCP connection cannot be seen as the same as an SCTP association with 1 single stream? And what is your reason that "reusing a stream" requires "resetting a stream"? -- K. Poon. ka-cheong.poon at oracle.com From touch at isi.edu Fri Mar 25 08:16:33 2011 From: touch at isi.edu (Joe Touch) Date: Fri, 25 Mar 2011 08:16:33 -0700 Subject: [e2e] TCP sequence number reset In-Reply-To: <4D8C32C7.8060904@oracle.com> References: <4D8AF82F.8060100@oracle.com> <20110324133849.GC19194@locust.cns.vt.edu> <4D8B75F2.2080107@oracle.com> <4D8BC9EF.4060207@isi.edu> <4D8C21CC.9090608@oracle.com> <4D8C24E4.6060401@isi.edu> <4D8C32C7.8060904@oracle.com> Message-ID: <4D8CB1D1.5090702@isi.edu> On 3/24/2011 11:14 PM, Kacheong Poon wrote: > On 03/25/11 01:15 PM, Joe Touch wrote: > >> The SCTP TSN is similar to TCP's sequence number, but due to the >> relationship to the SSNs they're not directly related. Resetting the TSN >> appears to be useful only in relation to resetting all the SSNs at once, >> since they are based on the TSN. The document lacks any direct rationale >> for TSN reset other than this, which is implied (this should be >> explicitly addressed, IMO). >> >> There's no notion of separate streams in TCP, so there's no purpose in >> resetting TCP's sequence number, thus the analogy doesn't hold. > > What is your reason that a TCP connection cannot be seen as the same > as an SCTP association with 1 single stream? TCP never ever communicates anything to the user based on the seqno. SCTP derives SSNs from the TSN (from the draft): Stream Reset Request Sequence Number: 4 bytes (unsigned integer) This field is used to identify the request. It is a monotonically increasing number that is initialized to the same value as the Initial TSN number. It is increased by 1 whenever sending a new Stream Reset Request parameter. (note that this is a significant change from RFC 2960: 1.3.4 Acknowledgement and Congestion Avoidance SCTP assigns a Transmission Sequence Number (TSN) to each user data fragment or unfragmented message. The TSN is independent of any stream sequence number assigned at the stream level. and the SSN has specific user-level semantics (RFC 2960): The stream sequence number in all the streams shall start from 0 when the association is established. Thus resetting the SSN is required to reuse a stream. > And what is your > reason that "reusing a stream" requires "resetting a stream"? See above, from RFC 2960. In TCP, by comparison, the seqno is never meaningful to the user; resetting it has no purpose. Joe From detlef.bosau at web.de Sun Mar 27 07:46:01 2011 From: detlef.bosau at web.de (Detlef Bosau) Date: Sun, 27 Mar 2011 16:46:01 +0200 Subject: [e2e] TCP sequence number reset In-Reply-To: <4D8C32C7.8060904@oracle.com> References: <4D8AF82F.8060100@oracle.com> <20110324133849.GC19194@locust.cns.vt.edu> <4D8B75F2.2080107@oracle.com> <4D8BC9EF.4060207@isi.edu> <4D8C21CC.9090608@oracle.com> <4D8C24E4.6060401@isi.edu> <4D8C32C7.8060904@oracle.com> Message-ID: <4D8F4DA9.5000803@web.de> On 03/25/2011 07:14 AM, Kacheong Poon wrote: > > What is your reason that a TCP connection cannot be seen as the same > as an SCTP association with 1 single stream? And what is your > reason that "reusing a stream" requires "resetting a stream"? > > At least one reason is that a sequence number in TCP is never defined by the user but negotiated in the startup phase of the flow. Particularly, refer e.g. to RFC 793, recently used sequence numbers must not be used for a certain period of time. In my opinion, your problem is twofold. First, you propose mechanisms, such as resetting a TCP sequence number by the user, without giving a clear reason for doing so. And please keep in mind, that in science, we must give valid reasons for taking a certain decision. Particularly this holds true for adding mechanisms to protocols. Second, and admittedly I'm not quite familiar with SCTP, so I don't know the API/user view for it, any kind of protocol design is strongly governed by the abstraction we wand to achieve and the behaviour, which is presented to the user. And particularly, TCP provides a user with an ordered and reliable stream of octets. Particularly, there is no random access to this stream. In that respect, a TCP flow between two endpoints resembles an inter process pipe. From that point of view, there is absolutely no need for an application to deal with certain sequence numbers. Detlef From ka-cheong.poon at oracle.com Mon Mar 28 02:54:15 2011 From: ka-cheong.poon at oracle.com (Kacheong Poon) Date: Mon, 28 Mar 2011 17:54:15 +0800 Subject: [e2e] TCP sequence number reset In-Reply-To: <4D8CB1D1.5090702@isi.edu> References: <4D8AF82F.8060100@oracle.com> <20110324133849.GC19194@locust.cns.vt.edu> <4D8B75F2.2080107@oracle.com> <4D8BC9EF.4060207@isi.edu> <4D8C21CC.9090608@oracle.com> <4D8C24E4.6060401@isi.edu> <4D8C32C7.8060904@oracle.com> <4D8CB1D1.5090702@isi.edu> Message-ID: <4D905AC7.5040403@oracle.com> On 03/25/11 11:16 PM, Joe Touch wrote: > TCP never ever communicates anything to the user based on the seqno. As I mentioned in my original email, "assuming an app can get the sequence number." If a stack wants to export TCP sequence number, it is very simple to do. And to create a concept of SSN as in SCTP, it just maps IRS (initial receive sequence number) to 0 and you get the equivalence of SSN. So with this simple mapping, why do you still think that a TCP connection is not the same as an SCTP association with one single stream? > SCTP derives SSNs from the TSN (from the draft): > > Stream Reset Request Sequence Number: 4 bytes (unsigned integer) > This field is used to identify the request. It is a monotonically > increasing number that is initialized to the same value as the > Initial TSN number. It is increased by 1 whenever sending a new > Stream Reset Request parameter. This number, Stream Reset Request Sequence Number, has nothing to do with SCTP SSN and TSN. It is just a number to identify a request. It is just part of the protocol mechanism introduced for TSN/SSN resetting. And it does not need to be initialized to initial TSN number. My question is not about the mechanism. My question is about how people think about the idea of TCP sequence number reset (which is just a simple mapping of what the draft proposed). > (note that this is a significant change from RFC 2960: > 1.3.4 Acknowledgement and Congestion Avoidance > > SCTP assigns a Transmission Sequence Number (TSN) to each user data > fragment or unfragmented message. The TSN is independent of any > stream sequence number assigned at the stream level. > > and the SSN has specific user-level semantics (RFC 2960): > > The stream sequence number in all the streams shall start from 0 when > the association is established. > > Thus resetting the SSN is required to reuse a stream. ?? When asked about the "stream reuse usage", the authors mentioned one example in the WG mailing list, which is sending multiple files in one stream. So stream reset signifies an EOF of one file. Is this your idea of "stream reuse?" > > And what is your >> reason that "reusing a stream" requires "resetting a stream"? > > See above, from RFC 2960. > > In TCP, by comparison, the seqno is never meaningful to the user; > resetting it has no purpose. Please read the draft and my original question carefully before jumping to conclusion. -- K. Poon. ka-cheong.poon at oracle.com From ka-cheong.poon at oracle.com Mon Mar 28 03:05:14 2011 From: ka-cheong.poon at oracle.com (Kacheong Poon) Date: Mon, 28 Mar 2011 18:05:14 +0800 Subject: [e2e] TCP sequence number reset In-Reply-To: <4D8F4DA9.5000803@web.de> References: <4D8AF82F.8060100@oracle.com> <20110324133849.GC19194@locust.cns.vt.edu> <4D8B75F2.2080107@oracle.com> <4D8BC9EF.4060207@isi.edu> <4D8C21CC.9090608@oracle.com> <4D8C24E4.6060401@isi.edu> <4D8C32C7.8060904@oracle.com> <4D8F4DA9.5000803@web.de> Message-ID: <4D905D5A.2010208@oracle.com> On 03/27/11 10:46 PM, Detlef Bosau wrote: > At least one reason is that a sequence number in TCP is never defined by > the user but negotiated in the startup phase of the flow. > Particularly, refer e.g. to RFC 793, recently used sequence numbers must > not be used for a certain period of time. As I mentioned in my original email, I made the assumption that TCP sequence number can be accessed by applications. In my reply to Joe Touch's email, it is just a very simple mapping. We can discuss whether this is a good idea to export this number. But this is orthogonal to my question. My question is why does one want to reset TCP sequence number? > In my opinion, your problem is twofold. > > First, you propose mechanisms, such as resetting a TCP sequence number > by the user, without giving a clear reason for doing so. And please keep > in mind, that in science, we must give valid reasons for taking a > certain decision. Particularly this holds true for adding mechanisms to > protocols. Note that it is not "my" proposal. It is a proposal by the authors of the draft I mentioned and I am not one of the authors. I just map it to TCP which is a better known transport protocol so that more people can comment, even without knowing about SCTP. The mapping is simple and straight forward. > Second, and admittedly I'm not quite familiar with SCTP, so I don't know > the API/user view for it, any kind of protocol design is strongly > governed by the abstraction we wand to achieve and the behaviour, which > is presented to the user. And particularly, TCP provides a user with an > ordered and reliable stream of octets. Particularly, there is no random > access to this stream. In that respect, a TCP flow between two endpoints > resembles an inter process pipe. From that point of view, there is > absolutely no need for an application to deal with certain sequence > numbers. What you wrote above also holds for SCTP with 1 single stream. The reason to have a stream sequence number is that there can be multiple streams (a stream is like a TCP connection) in one SCTP association. Having an SSN makes the stack easier to deal with message ordering in each stream. -- K. Poon. ka-cheong.poon at oracle.com From touch at isi.edu Mon Mar 28 04:36:56 2011 From: touch at isi.edu (Joe Touch) Date: Mon, 28 Mar 2011 04:36:56 -0700 Subject: [e2e] TCP sequence number reset In-Reply-To: <4D905AC7.5040403@oracle.com> References: <4D8AF82F.8060100@oracle.com> <20110324133849.GC19194@locust.cns.vt.edu> <4D8B75F2.2080107@oracle.com> <4D8BC9EF.4060207@isi.edu> <4D8C21CC.9090608@oracle.com> <4D8C24E4.6060401@isi.edu> <4D8C32C7.8060904@oracle.com> <4D8CB1D1.5090702@isi.edu> <4D905AC7.5040403@oracle.com> Message-ID: <4D9072D8.3090400@isi.edu> Kacheong, > On 03/25/11 11:16 PM, Joe Touch wrote: > >> TCP never ever communicates anything to the user based on the seqno. > > As I mentioned in my original email, "assuming an app can > get the sequence number." If a stack wants to export TCP > sequence number, it is very simple to do. There is *no* correlation between TCP segments and the user interface so yes, we could modify the user interface to indicate a sequence number, but which one? when TCP receives data, it's buffered until ACKd; it's sent to the user after being ACKd. There is no "sequence number" associated with a received byte other than its offset from the start of the stream. Consider that a given byte could be received in multiple segments (esp. if a large segment is thought lost due to ACK loss and ends up being retransmitted as smaller segments, e.g., after a path MTU change). > And to create a > concept of SSN as in SCTP, it just maps IRS (initial receive > sequence number) to 0 and you get the equivalence of SSN. If you assume the initial number is 0, then you already get the relevant info by counting bytes. > So with this simple mapping, why do you still think that a > TCP connection is not the same as an SCTP association with > one single stream? The notion of such an ID isn't associated with a given byte in TCP; it is associated with a message in SCTP. >> (note that this is a significant change from RFC 2960: >> 1.3.4 Acknowledgement and Congestion Avoidance >> >> SCTP assigns a Transmission Sequence Number (TSN) to each user data >> fragment or unfragmented message. The TSN is independent of any >> stream sequence number assigned at the stream level. >> >> and the SSN has specific user-level semantics (RFC 2960): >> >> The stream sequence number in all the streams shall start from 0 when >> the association is established. >> >> Thus resetting the SSN is required to reuse a stream. > > > ?? When asked about the "stream reuse usage", the authors > mentioned one example in the WG mailing list, which is sending > multiple files in one stream. So stream reset signifies an > EOF of one file. Is this your idea of "stream reuse?" I would presume that's one use case. My problem with modifying TCP to support this is that it's going to require as much, if not more, mechanism than shutting the connection and starting a new one. In specific, there is *no* mechanism for stateful exchange of TCP options. if you want to reset the sequence number, at *best* you'll need to create a way to halt current data transmission (e.g., send an option), a way to wait for pending operations to complete (e.g., receive an option confirmation) and then a way to confirm the change (send an option confirmation). i.e., you'll recreate the SYN TWHS >> > And what is your >>> reason that "reusing a stream" requires "resetting a stream"? >> >> See above, from RFC 2960. >> >> In TCP, by comparison, the seqno is never meaningful to the user; >> resetting it has no purpose. > > Please read the draft and my original question carefully before > jumping to conclusion. You have one Internet draft currently active that refers to SCTP, not TCP. The title of your post talks about resetting TCP numbers, not SCTP numbers. So that document isn't particularly relevant to this email thread, except as inspiring the goal of a similar mechanism in TCP. Your original post states as follows, so let's go through it in detail: > Just want to get some opinion from the list members about an > idea proposed in an IETF draft. The equivalent idea when > applied to TCP is sequence number reset. The idea is that > assuming an application can access TCP sequence number with > each byte of data, Which above I have shown is undefined. > an app is allowed to reset the TCP sequence > number when it wants to. Which above I have explained is the same cost as starting a new connection. > The sequence number is set to a number > not acceptable (add 231) in the current connection. There is no sequence number which is unacceptable for a connection; all numbers are valid, it's just that some may refer to old segments and others may refer to segments not yet acknowledged. > Note that > there is no clear usage proposed in that draft nor any reason > that it is needed, just a mechanism to do it. It would be useful to explain a goal use, otherwise it's impossible to determine whether the mechanism is sufficient. ---- From marcel at wanda.ch Mon Mar 28 06:53:33 2011 From: marcel at wanda.ch (Marcel Waldvogel) Date: Mon, 28 Mar 2011 15:53:33 +0200 Subject: [e2e] TCP sequence number reset In-Reply-To: <4D905D5A.2010208@oracle.com> References: <4D8AF82F.8060100@oracle.com> <20110324133849.GC19194@locust.cns.vt.edu> <4D8B75F2.2080107@oracle.com> <4D8BC9EF.4060207@isi.edu> <4D8C21CC.9090608@oracle.com> <4D8C24E4.6060401@isi.edu> <4D8C32C7.8060904@oracle.com> <4D8F4DA9.5000803@web.de> <4D905D5A.2010208@oracle.com> Message-ID: Several questions need to be answered before we can decide on "Do we want to go through the hassle of resetting the sequence number?" 1. What sequence number (relative or absolute, see below) do you want to export to applications? 2. Why do you want to do it? (Or why may someone want to do so?) 3. What would be the semantics of this? 4. Why do you want to reset it? 5. If SCTP already has the functionality, why not use SCTP for applications requiring it? None of these questions have been answered so far. I am trying to structure the discussion a little bit by answering the first one and opening the second. The "relative" sequence number of a particular byte (relative to the ISN) can best be computed by the application itself, recording the number of bytes read so far. This way of counting also makes sure that the "right" thing is counted, i.e., what the application probably wants to know, which is likely not related to the internal TCP state of the connection endpoint. The application is then also free to define a mechanism to reset that variable, no transport protocol or interface changes needed. The "absolute" sequence number (the one transmit in SEQ and ACK fields) is probably of no use to a "normal" application and resetting it will cause major problems as outlined in previous mails. For the first ("relative") one, I do not see a need to change the API. Even if there were good uses for it, the application is free to count the bytes itself and reset counters at will and has the added advantage of remaining fully portable. The second ("absolute") case is dangerous and will likely cause all kinds of interoperability problems. Unless someone comes up with a use case, we should stop wasting our time discussion it further. As a result, even after the clarification from the first question, I see no way of positively answering the second question. -Marcel From detlef.bosau at web.de Mon Mar 28 09:01:11 2011 From: detlef.bosau at web.de (Detlef Bosau) Date: Mon, 28 Mar 2011 18:01:11 +0200 Subject: [e2e] TCP sequence number reset In-Reply-To: References: <4D8AF82F.8060100@oracle.com> <20110324133849.GC19194@locust.cns.vt.edu> <4D8B75F2.2080107@oracle.com> <4D8BC9EF.4060207@isi.edu> <4D8C21CC.9090608@oracle.com> <4D8C24E4.6060401@isi.edu> <4D8C32C7.8060904@oracle.com> <4D8F4DA9.5000803@web.de> <4D905D5A.2010208@oracle.com> Message-ID: <4D90B0C7.4010605@web.de> On 03/28/2011 03:53 PM, Marcel Waldvogel wrote: > > For the first ("relative") one, I do not see a need to change the API. Even if there were good uses for it, the application is free to count the bytes itself and reset counters at will and has the added advantage of remaining fully portable. In addition, changing the API may not even be sufficient, but the internal function of a socket would be subject to change as well. E.g., when an application could refer to some "extremely old" relative sequence number, it is well possible that some requested data is no longer available in the socket(s, both, sender side and receiver side as well) and the sending application. We should bear in mind that the sending application is free to discard any data which has been successfully written to the sending socket and the sending socket is free to discard any data, which has been acknowledged by the receiving socket. So, some reference to "old" data may point to data, which no longer exists neither in the socket nor in the sending application. The same holds true for any attempt to "roll back" a TCP stream to some state, any information for which was discarded long ago. As Eric pointed out, TCP is a distributed state machine with "loosely" coupled sockets. "Loosely coupled" in the sense that we have a soft state which is robust against packet loss or packet order distortion. Although packet loss or packet order distortion may lead to some throughput degradation, both is overcome without any severe harm to the flow itself. In contrast to that, a strict coupling of states between communication end points may lead to quite some two army problems, which may be quite cumbersome to deal with. Detlef From ka-cheong.poon at oracle.com Tue Mar 29 22:07:57 2011 From: ka-cheong.poon at oracle.com (Kacheong Poon) Date: Wed, 30 Mar 2011 13:07:57 +0800 Subject: [e2e] TCP sequence number reset In-Reply-To: <4D9072D8.3090400@isi.edu> References: <4D8AF82F.8060100@oracle.com> <20110324133849.GC19194@locust.cns.vt.edu> <4D8B75F2.2080107@oracle.com> <4D8BC9EF.4060207@isi.edu> <4D8C21CC.9090608@oracle.com> <4D8C24E4.6060401@isi.edu> <4D8C32C7.8060904@oracle.com> <4D8CB1D1.5090702@isi.edu> <4D905AC7.5040403@oracle.com> <4D9072D8.3090400@isi.edu> Message-ID: <4D92BAAD.3030901@oracle.com> I guess I should have first stated why I raised the question in e2e. I think the proposed draft about SCTP TSN/SSN mechanism is unjustified and should not be moved forward as a PS. That draft was at LC in TSVWG and I'd like to gather more opinion as there did not seem to have much discussion on the TSVWG mailing list from a transport protocol design perspective. And a more fundamental issue is that there is no supporting argument for having such a mechanism in SCTP except to re-use a stream to send multiple files. I cannot consider that a supporting reason. The problem is that it seems that I am the only person raising this question about that proposed SCTP mechanism in the mailing list. Hence I posted the question to e2e as I think there are more folks with transport protocol design experience whom can comment more. And since TCP is more widely known, I mapped the proposed mechanism to a TCP mechanism. And I deliberately did not mention that I had strong reservation about that draft hoping that folks want jump to conclusion and will give opinion on whether they think it is a good or bad idea. But it seems that this does exactly the opposite.... On 03/28/11 07:36 PM, Joe Touch wrote: > > As I mentioned in my original email, "assuming an app can > > get the sequence number." If a stack wants to export TCP > > sequence number, it is very simple to do. > > There is *no* correlation between TCP segments and the user interface > so yes, we could modify the user interface to indicate > a sequence number, but which one? when TCP receives data, > it's buffered until ACKd; it's sent to the user after > being ACKd. There is no "sequence number" associated with > a received byte other than its offset from the start of > the stream. Consider that a given byte could be received > in multiple segments (esp. if a large segment is thought lost > due to ACK loss and ends up being retransmitted as smaller > segments, e.g., after a path MTU change). Using the BSD socket interface to do the mapping, it is simple to send up an ancillary data with each recvmsg() call which contains the TCP sequence number of the first received byte. One can argue if that is useful, but is easily done. > > And to create a > > concept of SSN as in SCTP, it just maps IRS (initial receive > > sequence number) to 0 and you get the equivalence of SSN. > > If you assume the initial number is 0, then you already get the > relevant info by counting bytes. Right. That's why I said it's an easy mapping to TCP. IMHO, the mapping is not key to my question. I want to see if folks on this list see a reason why resetting TCP sequence number can be useful. There is one comment on the TSVWG mailing list that TSN/SSN reset is useful to "unknot network situation." I don't know what network situation that is and what "unknot" really means. But maybe folks in e2e know better than I. > In specific, there is *no* mechanism for stateful exchange of TCP options. > if you want to reset the sequence number, at *best* > you'll need to create a way to halt current data > transmission (e.g., send an option), a way to wait > for pending operations to complete (e.g., receive > an option confirmation) and then a way to confirm > the change (send an option confirmation). > > i.e., you'll recreate the SYN TWHS In fact, this is similar to the proposed SCTP mechanism. I don't see why we need to introduce a mechanism at the transport layer just to support something which can easily be done at the app layer. > You have one Internet draft currently active that refers to SCTP, not > TCP. The title of your post talks about resetting TCP numbers, not SCTP > numbers. So that document isn't particularly relevant to this email > thread, except as inspiring the goal of a similar mechanism in TCP. I guess I should have stated my reason in raising the question... > Your original post states as follows, so let's go through it in detail: > >> Just want to get some opinion from the list members about an >> idea proposed in an IETF draft. The equivalent idea when >> applied to TCP is sequence number reset. The idea is that >> assuming an application can access TCP sequence number with >> each byte of data, > > Which above I have shown is undefined. As I mentioned, it can be defined. > > an app is allowed to reset the TCP sequence >> number when it wants to. > > Which above I have explained is the same cost as starting a new connection. I agree. It is this kind of opinion that I want to gather from this list. > > The sequence number is set to a number >> not acceptable (add 231) in the current connection. > > There is no sequence number which is unacceptable for a connection; all > numbers are valid, it's just that some may refer to old segments and > others may refer to segments not yet acknowledged. A sequence number outside the TCP receive window is not acceptable. It is defined in RFC 793. > > Note that >> there is no clear usage proposed in that draft nor any reason >> that it is needed, just a mechanism to do it. > > It would be useful to explain a goal use, otherwise it's impossible to > determine whether the mechanism is sufficient. This was exactly my question raised in the TSVWG mailing list... -- K. Poon. ka-cheong.poon at oracle.com From ka-cheong.poon at oracle.com Tue Mar 29 22:36:29 2011 From: ka-cheong.poon at oracle.com (Kacheong Poon) Date: Wed, 30 Mar 2011 13:36:29 +0800 Subject: [e2e] TCP sequence number reset In-Reply-To: References: <4D8AF82F.8060100@oracle.com> <20110324133849.GC19194@locust.cns.vt.edu> <4D8B75F2.2080107@oracle.com> <4D8BC9EF.4060207@isi.edu> <4D8C21CC.9090608@oracle.com> <4D8C24E4.6060401@isi.edu> <4D8C32C7.8060904@oracle.com> <4D8F4DA9.5000803@web.de> <4D905D5A.2010208@oracle.com> Message-ID: <4D92C15D.7050602@oracle.com> As I mentioned in my reply to Joe Touch, I am not trying to propose such a TCP mechanism. I just mapped the proposed SCTP mechanism to TCP since TCP is more widely known and probably will generate more comments. And I think your comments below can be mapped to SCTP and still be applicable. It is this sort of comments which I'd like to gather since I am probably the only person in the TSVWG mailing list who has reservation on the proposed SCTP mechanism. On 03/28/11 09:53 PM, Marcel Waldvogel wrote: > Several questions need to be answered before we can decide on "Do we want to go through the hassle of resetting the sequence number?" > 1. What sequence number (relative or absolute, see below) do you want to export to applications? > 2. Why do you want to do it? (Or why may someone want to do so?) > 3. What would be the semantics of this? > 4. Why do you want to reset it? > 5. If SCTP already has the functionality, why not use SCTP for applications requiring it? > None of these questions have been answered so far. I am trying to structure the discussion a little bit by answering the first one and opening the second. > > The "relative" sequence number of a particular byte (relative to the ISN) can best be computed by the application itself, recording the number of bytes read so far. This way of counting also makes sure that the "right" thing is counted, i.e., what the application probably wants to know, which is likely not related to the internal TCP state of the connection endpoint. The application is then also free to define a mechanism to reset that variable, no transport protocol or interface changes needed. > > The "absolute" sequence number (the one transmit in SEQ and ACK fields) is probably of no use to a "normal" application and resetting it will cause major problems as outlined in previous mails. > > For the first ("relative") one, I do not see a need to change the API. Even if there were good uses for it, the application is free to count the bytes itself and reset counters at will and has the added advantage of remaining fully portable. > > The second ("absolute") case is dangerous and will likely cause all kinds of interoperability problems. Unless someone comes up with a use case, we should stop wasting our time discussion it further. > > As a result, even after the clarification from the first question, I see no way of positively answering the second question. > > -Marcel > -- K. Poon. ka-cheong.poon at oracle.com From touch at isi.edu Tue Mar 29 23:25:36 2011 From: touch at isi.edu (Joe Touch) Date: Tue, 29 Mar 2011 23:25:36 -0700 Subject: [e2e] TCP sequence number reset In-Reply-To: <4D92BAAD.3030901@oracle.com> References: <4D8AF82F.8060100@oracle.com> <20110324133849.GC19194@locust.cns.vt.edu> <4D8B75F2.2080107@oracle.com> <4D8BC9EF.4060207@isi.edu> <4D8C21CC.9090608@oracle.com> <4D8C24E4.6060401@isi.edu> <4D8C32C7.8060904@oracle.com> <4D8CB1D1.5090702@isi.edu> <4D905AC7.5040403@oracle.com> <4D9072D8.3090400@isi.edu> <4D92BAAD.3030901@oracle.com> Message-ID: <4D92CCE0.8070005@isi.edu> Hi, Kacheong, On 3/29/2011 10:07 PM, Kacheong Poon wrote: > I guess I should have first stated why I raised the question > in e2e. I think the proposed draft about SCTP TSN/SSN mechanism > is unjustified and should not be moved forward as a PS. ... > Hence I posted the question to e2e as I think there are more > folks with transport protocol design experience whom can > comment more. And since TCP is more widely known, I mapped > the proposed mechanism to a TCP mechanism. My concern is that moving this mechanism over to TCP is meaningless. If you really want to focus on the SCTP mechanism, perhaps it would be more useful to start a thread on that directly; there are many on this list familiar with SCTP. Later you say: > IMHO, > the mapping is not key to my question. I want to see if folks > on this list see a reason why resetting TCP sequence number > can be useful. There is one comment on the TSVWG mailing list > that TSN/SSN reset is useful to "unknot network situation." I > don't know what network situation that is and what "unknot" really > means. But maybe folks in e2e know better than I. I don't know specifically what the SCTP reset could be useful for, but it doesn't make sense to talk about it in the context of TCP at all, so TCP is not a good example for the discussion you seek. --- Since this thread focuses on the TCP version, the remainder of my comments focus on that (as have most of my prior ones): > On 03/28/11 07:36 PM, Joe Touch wrote: > >> > As I mentioned in my original email, "assuming an app can >> > get the sequence number." If a stack wants to export TCP >> > sequence number, it is very simple to do. >> >> There is *no* correlation between TCP segments and the user interface >> so yes, we could modify the user interface to indicate >> a sequence number, but which one? when TCP receives data, >> it's buffered until ACKd; it's sent to the user after >> being ACKd. There is no "sequence number" associated with >> a received byte other than its offset from the start of >> the stream. Consider that a given byte could be received >> in multiple segments (esp. if a large segment is thought lost >> due to ACK loss and ends up being retransmitted as smaller >> segments, e.g., after a path MTU change). > > Using the BSD socket interface to do the mapping, it is simple > to send up an ancillary data with each recvmsg() call which > contains the TCP sequence number of the first received byte. > One can argue if that is useful, but is easily done. A given received byte has an offset from the beginning of the stream, which is trivially counted (without augmenting the current API). A given received byte has no other related sequence number. I think you *want* a byte to be tagged with the sequence number of the segment in which it was received. However, that is ambiguous. Consider the following (I made the numbers smaller to make the example easier to type): X thinks the PMTU is 6 X sends ABCDEF seqno 0 X receives an ICMP 'too big', saying 3 bytes are OK X times out, and so sends: ABC seqno 0 DEF seqno 4 Now let's look at the receive side: Y reads ABCDEF What is the seqno of D? Well, if the first ABCDEF went through, then it's 0 If it was lost, and then the other two packets arrive out of order, then the entire ABCDEF is presented to the user when DEF shows up, at which point ABC all have seqno 0 and DEF all have seqno 4 To make matters worse, ABCDEF could have arrived *and* ABC DEF too. So the receiver could think that D has the following seqnos: 0 4 0 *and* 4 So which is it? Presenting a seqno to the user implies that TCP segments are meaningful to the user. They're simply not. TCP is allowed to segment as desired - regardless of how data is presented, and can re-segment as needed during retransmission. To say that the seqno reset means anything is to say the seqno means something, and it simply doesn't. It's an offset for data reassembly, that's all. You really want a flag in the middle of the stream. The closest thing to this is the URG pointer, whose use has been deprecated, and had similar problems with correlating an out-of-band E2E signal with in-band data. TCP simply doesn't have a way to do that. SCTP does, which is why the reset mechanism is meaningful there (albeit perhaps not useful for any particular purpose), but isn't here. ... >> > The sequence number is set to a number >>> not acceptable (add 231) in the current connection. >> >> There is no sequence number which is unacceptable for a connection; all >> numbers are valid, it's just that some may refer to old segments and >> others may refer to segments not yet acknowledged. > > A sequence number outside the TCP receive window is not > acceptable. It is defined in RFC 793. Sequence numbers of any value can always arrive; numbers outside the window are packets that are too old to arrive correctly, so that's why they're dropped. All sequence numbers could appear on the wire at any time - if you start using "unexpected" numbers for other purposes, you defeat an explicit protection mechanism in TCP. Joe From ka-cheong.poon at oracle.com Wed Mar 30 00:33:47 2011 From: ka-cheong.poon at oracle.com (Kacheong Poon) Date: Wed, 30 Mar 2011 15:33:47 +0800 Subject: [e2e] TCP sequence number reset In-Reply-To: <4D92CCE0.8070005@isi.edu> References: <4D8AF82F.8060100@oracle.com> <20110324133849.GC19194@locust.cns.vt.edu> <4D8B75F2.2080107@oracle.com> <4D8BC9EF.4060207@isi.edu> <4D8C21CC.9090608@oracle.com> <4D8C24E4.6060401@isi.edu> <4D8C32C7.8060904@oracle.com> <4D8CB1D1.5090702@isi.edu> <4D905AC7.5040403@oracle.com> <4D9072D8.3090400@isi.edu> <4D92BAAD.3030901@oracle.com> <4D92CCE0.8070005@isi.edu> Message-ID: <4D92DCDB.6070000@oracle.com> On 03/30/11 02:25 PM, Joe Touch wrote: > My concern is that moving this mechanism over to TCP is meaningless. If > you really want to focus on the SCTP mechanism, perhaps it would be more > useful to start a thread on that directly; there are many on this list > familiar with SCTP. Right, that probably is better. But I still think that the mapping is OK. See below. > A given received byte has an offset from the beginning of the stream, > which is trivially counted (without augmenting the current API). > > A given received byte has no other related sequence number. I think you > *want* a byte to be tagged with the sequence number of the segment in > which it was received. However, that is ambiguous. Consider the > following (I made the numbers smaller to make the example easier to type): Each bytes sent in a TCP connection has a TCP sequence number attached to it. In the example case below, > X thinks the PMTU is 6 > X sends > ABCDEF seqno 0 > X receives an ICMP 'too big', saying 3 bytes are OK > X times out, and so sends: > ABC seqno 0 > DEF seqno 4 > > Now let's look at the receive side: > > Y reads ABCDEF > > What is the seqno of D? It is still 4. Regardless of the TCP level segmentation, each bytes has its own TCP sequence number. > Well, if the first ABCDEF went through, then it's 0 > If it was lost, and then the other two packets arrive out of order, > then the entire ABCDEF is presented to the user when DEF shows up, at > which point ABC all have seqno 0 and DEF all have seqno 4 The simple mapping I suggested was to send up the same TCP level sequence number to the app. So regardless of the order a segment arrives, the sequence number won't change. > To make matters worse, ABCDEF could have arrived *and* ABC DEF too. This is fine. TCP discards duplicated segment. There is no duplicated sequence number sent up to the app. > So the receiver could think that D has the following seqnos: > 0 > 4 > 0 *and* 4 > > So which is it? Your idea of mapping is not the same as my idea of simple mapping. Simple mapping should be simple :-) You are making it more complicated than necessary. I am not saying that letting an app know about TCP sequence number is useful. In fact, I don't believe an app needs to know about SCTP TSN or SSN either. > Presenting a seqno to the user implies that TCP segments are meaningful > to the user. They're simply not. TCP is allowed to segment as desired - > regardless of how data is presented, and can re-segment as needed during > retransmission. This is not necessary. The app does not need to care about TCP segmentation. > To say that the seqno reset means anything is to say the seqno means > something, and it simply doesn't. It's an offset for data reassembly, > that's all. The mapping to TCP is that an app can tell the TCP stack its use of sequence number should be reset (changed). Suppose current tcp_snxt is S. When TCP sends the next segment, the sequence number in that segment's TCP header will be S. But if a reset has happend, that sequence number will be something else. In SCTP's case, the TSN has the same meaning as TCP sequence number. Just consider this simple case, every SCTP message is 1 byte long. Then SCTP TSN and TCP sequence number means exactly the same thing. > You really want a flag in the middle of the stream. The closest thing to > this is the URG pointer, whose use has been deprecated, and had similar > problems with correlating an out-of-band E2E signal with in-band data. As I mentioned, how to do the reset in TCP is orthogonal to my question. The question is do folks think that an app should care about TCP sequence number at all. And I think the reasons map to SCTP as well. > TCP simply doesn't have a way to do that. SCTP does, which is why the > reset mechanism is meaningful there (albeit perhaps not useful for any > particular purpose), but isn't here. Why do you think that reset is useful? SCTP currently does not have a way to reset TSN/SSN, just like TCP. How to design such a mechanism is the next question to ask when we are sure that resetting is useful at the transport level. > ... >>> > The sequence number is set to a number >>>> not acceptable (add 231) in the current connection. >>> >>> There is no sequence number which is unacceptable for a connection; all >>> numbers are valid, it's just that some may refer to old segments and >>> others may refer to segments not yet acknowledged. >> >> A sequence number outside the TCP receive window is not >> acceptable. It is defined in RFC 793. > > Sequence numbers of any value can always arrive; numbers outside the > window are packets that are too old to arrive correctly, so that's why > they're dropped. All sequence numbers could appear on the wire at any > time - if you start using "unexpected" numbers for other purposes, you > defeat an explicit protection mechanism in TCP. This is how the proposed SCTP mechanism works. It is not my idea. -- K. Poon. ka-cheong.poon at oracle.com From ka-cheong.poon at oracle.com Wed Mar 30 00:39:54 2011 From: ka-cheong.poon at oracle.com (Kacheong Poon) Date: Wed, 30 Mar 2011 15:39:54 +0800 Subject: [e2e] TCP sequence number reset In-Reply-To: References: <4D8AF82F.8060100@oracle.com> <20110324133849.GC19194@locust.cns.vt.edu> <4D8B75F2.2080107@oracle.com> <4D8BC9EF.4060207@isi.edu> <4D8C21CC.9090608@oracle.com> <4D8C24E4.6060401@isi.edu> <4D8C32C7.8060904@oracle.com> <4D8CB1D1.5090702@isi.edu> <4D905AC7.5040403@oracle.com> <4D9072D8.3090400@isi.edu> <4D92BAAD.3030901@oracle.com> Message-ID: <4D92DE4A.7000102@oracle.com> On 03/30/11 02:52 PM, Dave Hart wrote: > I sympathize with your concern there are not enough eyes in the WG. > It's a bit of an endemic problem on with IETF WGs. Perhaps your > energy would be better spent addressing that problem directly. > Alternatively, consider bringing the issue up outside the WG without > the broken analogy. While I am not familiar with SCTP (aside from > what I've learned in this thread), I think you have failed to make > your best case. I have no idea why re-using stream to send multiple > files is ill-advised or why you "cannot consider that a supporting > reason." It seems like a supporting reason on its face to me, but > perhaps there's a downside you've failed to illuminate. I'm sorry that I was not clear. There is nothing wrong to re-use an SCTP stream to send multiple files. The problem is that there is no reason why this needs a transport layer mechanism. For example, HTTP can send multiple files using the same TCP connection without restarting/resetting at the TCP level. There is no reason why an app requires an SCTP stream to be reset (which needs careful coordination between both sides) just to send multiple files using the same SCTP stream (which can be treated as a TCP connection). -- K. Poon. ka-cheong.poon at oracle.com From touch at isi.edu Wed Mar 30 00:47:28 2011 From: touch at isi.edu (Joe Touch) Date: Wed, 30 Mar 2011 00:47:28 -0700 Subject: [e2e] TCP sequence number reset In-Reply-To: <4D92DCDB.6070000@oracle.com> References: <4D8AF82F.8060100@oracle.com> <20110324133849.GC19194@locust.cns.vt.edu> <4D8B75F2.2080107@oracle.com> <4D8BC9EF.4060207@isi.edu> <4D8C21CC.9090608@oracle.com> <4D8C24E4.6060401@isi.edu> <4D8C32C7.8060904@oracle.com> <4D8CB1D1.5090702@isi.edu> <4D905AC7.5040403@oracle.com> <4D9072D8.3090400@isi.edu> <4D92BAAD.3030901@oracle.com> <4D92CCE0.8070005@isi.edu> <4D92DCDB.6070000@oracle.com> Message-ID: <4D92E010.6030809@isi.edu> Hi, Kacheong, On 3/30/2011 12:33 AM, Kacheong Poon wrote: ... > Each bytes sent in a TCP connection has a TCP sequence number > attached to it. In the example case below, > > >> X thinks the PMTU is 6 >> X sends >> ABCDEF seqno 0 >> X receives an ICMP 'too big', saying 3 bytes are OK >> X times out, and so sends: >> ABC seqno 0 >> DEF seqno 4 >> >> Now let's look at the receive side: >> >> Y reads ABCDEF >> >> What is the seqno of D? > > > It is still 4. Regardless of the TCP level segmentation, each > bytes has its own TCP sequence number. The receiver already knows that; it can just count as it reads bytes. That's the point I made very early on... >> Well, if the first ABCDEF went through, then it's 0 >> If it was lost, and then the other two packets arrive out of order, >> then the entire ABCDEF is presented to the user when DEF shows up, at >> which point ABC all have seqno 0 and DEF all have seqno 4 > > > The simple mapping I suggested was to send up the same TCP level > sequence number to the app. So regardless of the order a segment > arrives, the sequence number won't change. AOK - you clearly don't need to even send that. It's trivial to determine now without augmenting the API: tot_offset = 0 while (count = read(buf)) { offset of buf[i] is "tot_offset + i" just before looping: tot_offset += count; } So your simple map is already possible. What you *really* want is: a boundary in the TCP stream and everything before that boundary is part of one thing (the first stream) and everything after that boundary is part of the second. This has *nothing* to do with resetting the seqno. The seqno is irrelevant to establishing this boundary. Many have tried to find a way to put such a boundary in TCP, and it basically requires adding another state to the state diagram, and dealing with entering and leaving that state. The work required is the same as a 3WHS, which is why this has been abandoned. Joe From ka-cheong.poon at oracle.com Wed Mar 30 01:15:21 2011 From: ka-cheong.poon at oracle.com (Kacheong Poon) Date: Wed, 30 Mar 2011 16:15:21 +0800 Subject: [e2e] TCP sequence number reset In-Reply-To: <4D92E010.6030809@isi.edu> References: <4D8AF82F.8060100@oracle.com> <20110324133849.GC19194@locust.cns.vt.edu> <4D8B75F2.2080107@oracle.com> <4D8BC9EF.4060207@isi.edu> <4D8C21CC.9090608@oracle.com> <4D8C24E4.6060401@isi.edu> <4D8C32C7.8060904@oracle.com> <4D8CB1D1.5090702@isi.edu> <4D905AC7.5040403@oracle.com> <4D9072D8.3090400@isi.edu> <4D92BAAD.3030901@oracle.com> <4D92CCE0.8070005@isi.edu> <4D92DCDB.6070000@oracle.com> <4D92E010.6030809@isi.edu> Message-ID: <4D92E699.609@oracle.com> On 03/30/11 03:47 PM, Joe Touch wrote: >> It is still 4. Regardless of the TCP level segmentation, each >> bytes has its own TCP sequence number. > > The receiver already knows that; it can just count as it reads bytes. > That's the point I made very early on... Right, the receiver just needs to know about the TCP IRS, it then knows about the other sequence number. It is the same as in SCTP. A receiver knows the TSN of all messages if it knows the initial TSN. An app does not really need to care about TSN. The same thing can be applied to SSN since SSN serves the same purpose as TSN, just at the stream level. > So your simple map is already possible. That's what I've been saying. > What you *really* want is: > > a boundary in the TCP stream > > and everything before that boundary is part of one thing (the first > stream) and everything after that boundary is part of the second. The mapping from SCTP to TCP is that there is only 1 stream. So there is no such stream boundary needed. > This has *nothing* to do with resetting the seqno. The seqno is > irrelevant to establishing this boundary. No, it is not relevant. But I think this is also not relevant to TSN/SSN reset. > Many have tried to find a way to put such a boundary in TCP, and it > basically requires adding another state to the state diagram, and > dealing with entering and leaving that state. The work required is the > same as a 3WHS, which is why this has been abandoned. No, I am not trying to propose such a mechanism. My question is before we even try to design such a mechanism, is the problem worthwhile to be solved. This is the question to the TSN/SSN reset mechanism. -- K. Poon. ka-cheong.poon at oracle.com From touch at isi.edu Wed Mar 30 01:44:13 2011 From: touch at isi.edu (Joe Touch) Date: Wed, 30 Mar 2011 01:44:13 -0700 Subject: [e2e] TCP sequence number reset In-Reply-To: <4D92E699.609@oracle.com> References: <4D8AF82F.8060100@oracle.com> <20110324133849.GC19194@locust.cns.vt.edu> <4D8B75F2.2080107@oracle.com> <4D8BC9EF.4060207@isi.edu> <4D8C21CC.9090608@oracle.com> <4D8C24E4.6060401@isi.edu> <4D8C32C7.8060904@oracle.com> <4D8CB1D1.5090702@isi.edu> <4D905AC7.5040403@oracle.com> <4D9072D8.3090400@isi.edu> <4D92BAAD.3030901@oracle.com> <4D92CCE0.8070005@isi.edu> <4D92DCDB.6070000@oracle.com> <4D92E010.6030809@isi.edu> <4D92E699.609@oracle.com> Message-ID: <4D92ED5D.9020101@isi.edu> Let's start with the punchline, before we revisit details: >> Many have tried to find a way to put such a boundary in TCP, and >> it basically requires adding another state to the state diagram, >> and dealing with entering and leaving that state. The work required >> is the same as a 3WHS, which is why this has been abandoned. > > No, I am not trying to propose such a mechanism. My question > is before we even try to design such a mechanism, is the > problem worthwhile to be solved. This is the question to the > TSN/SSN reset mechanism. This really then comes back to one of two points. Either: 1) you have a real problem you want solved which, AFAICT, you are claiming has not been shown for SCTP, and you are not proposing 2) you have a solution which has some useful properties which we could then consider as possibly useful for something AFAICT, the solution in TCP is either not feasible, or costs as much as a new connection (and with less complexity), at which point this is not a good motivator So we're stuck with either hacking on the solution until we think it works in a way that provides a benefit worth the cost, OR finding a reason to develop a solution. Since neither seems to be the case, the rest of this discussion seems to be moot. Some points below *if* we want to continue to discuss the TCP version, but if we're not focusing on a TCP version, just skip them. Joe On 3/30/2011 1:15 AM, Kacheong Poon wrote: > On 03/30/11 03:47 PM, Joe Touch wrote: > >>> It is still 4. Regardless of the TCP level segmentation, each >>> bytes has its own TCP sequence number. >> >> The receiver already knows that; it can just count as it reads bytes. >> That's the point I made very early on... > > > Right, the receiver just needs to know about the TCP IRS, > it then knows about the other sequence number. It is the > same as in SCTP. A receiver knows the TSN of all messages > if it knows the initial TSN. An app does not really need > to care about TSN. The same thing can be applied to SSN > since SSN serves the same purpose as TSN, just at the stream > level. > > >> So your simple map is already possible. > > > That's what I've been saying. No; you've been saying you need to augment the API. I've claimed (and now shown) that the required info is already available. However, you don't really need this at all - you really need to know 'before' and 'after' some boundary, as per below. But let's please not focus on the mechanism if it's not important (as per above) >> What you *really* want is: >> >> a boundary in the TCP stream >> >> and everything before that boundary is part of one thing (the first >> stream) and everything after that boundary is part of the second. > > > The mapping from SCTP to TCP is that there is only 1 stream. > So there is no such stream boundary needed. OK, now you lost me. The ONLY reason to reset the TCP sequence number is to have two sequences - one before the reset, one after. I.e., two streams. We agree that's not what TCP does, but that's what you want. My point is that this is not possible in TCP. But let's please not focus on the mechanism if it's not important (as per above). From ka-cheong.poon at oracle.com Wed Mar 30 01:55:54 2011 From: ka-cheong.poon at oracle.com (Kacheong Poon) Date: Wed, 30 Mar 2011 16:55:54 +0800 Subject: [e2e] SCTP TSN/SSN reset In-Reply-To: <4D92ED5D.9020101@isi.edu> References: <4D8AF82F.8060100@oracle.com> <20110324133849.GC19194@locust.cns.vt.edu> <4D8B75F2.2080107@oracle.com> <4D8BC9EF.4060207@isi.edu> <4D8C21CC.9090608@oracle.com> <4D8C24E4.6060401@isi.edu> <4D8C32C7.8060904@oracle.com> <4D8CB1D1.5090702@isi.edu> <4D905AC7.5040403@oracle.com> <4D9072D8.3090400@isi.edu> <4D92BAAD.3030901@oracle.com> <4D92CCE0.8070005@isi.edu> <4D92DCDB.6070000@oracle.com> <4D92E010.6030809@isi.edu> <4D92E699.609@oracle.com> <4D92ED5D.9020101@isi.edu> Message-ID: <4D92F01A.2050908@oracle.com> On 03/30/11 04:44 PM, Joe Touch wrote: > This really then comes back to one of two points. Either: > > 1) you have a real problem you want solved > which, AFAICT, you are claiming has not been shown > for SCTP, and you are not proposing No, I don't see that there is a real problem to be solved which requires the transport level reset mechanism. This is my view. What I want to know if some folks on this list see that there is a real need which requires this mechanism. This has always been my question. > 2) you have a solution which has some useful properties which we could > then consider as possibly useful for something > AFAICT, the solution in TCP is either not feasible, > or costs as much as a new connection (and with less > complexity), at which point this is not a good > motivator No, the above is not what I proposed. I changed the subject line. So my question is do folks on this list think that a SCTP TSN/SSN reset is a useful feature to have. Basically, there is no real need for an app to know about TSN and SSN, let alone resetting them. There may be reasons that it is a good idea. This is what I want to hear from this list. -- K. Poon. ka-cheong.poon at oracle.com From detlef.bosau at web.de Wed Mar 30 05:40:19 2011 From: detlef.bosau at web.de (Detlef Bosau) Date: Wed, 30 Mar 2011 14:40:19 +0200 Subject: [e2e] TCP sequence number reset In-Reply-To: <4D92C15D.7050602@oracle.com> References: <4D8AF82F.8060100@oracle.com> <20110324133849.GC19194@locust.cns.vt.edu> <4D8B75F2.2080107@oracle.com> <4D8BC9EF.4060207@isi.edu> <4D8C21CC.9090608@oracle.com> <4D8C24E4.6060401@isi.edu> <4D8C32C7.8060904@oracle.com> <4D8F4DA9.5000803@web.de> <4D905D5A.2010208@oracle.com> <4D92C15D.7050602@oracle.com> Message-ID: <4D9324B3.2090706@web.de> I just had a very first glance at the discussion with you and Joe. And I think, Joes comments go into the same direction as those by Marcel. When your design goal / whatever can be accomplished by using SCTP, you should use it. There is no need to reinvent the wheel, there is even lesser need to reinvent TCP and to turn TCP into a worse SCTP. Perhaps you should focus more on the problem you want to solve instead of dealing with more or less useless analogies. Detlef -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de ------------------------------------------------------------------ From ka-cheong.poon at oracle.com Wed Mar 30 07:56:14 2011 From: ka-cheong.poon at oracle.com (Kacheong Poon) Date: Wed, 30 Mar 2011 22:56:14 +0800 Subject: [e2e] TCP sequence number reset In-Reply-To: <4D9324B3.2090706@web.de> References: <4D8AF82F.8060100@oracle.com> <20110324133849.GC19194@locust.cns.vt.edu> <4D8B75F2.2080107@oracle.com> <4D8BC9EF.4060207@isi.edu> <4D8C21CC.9090608@oracle.com> <4D8C24E4.6060401@isi.edu> <4D8C32C7.8060904@oracle.com> <4D8F4DA9.5000803@web.de> <4D905D5A.2010208@oracle.com> <4D92C15D.7050602@oracle.com> <4D9324B3.2090706@web.de> Message-ID: <4D93448E.6000502@oracle.com> On 03/30/11 08:40 PM, Detlef Bosau wrote: > I just had a very first glance at the discussion with you and Joe. And I > think, Joes comments go into the same direction as those by Marcel. > When your design goal / whatever can be accomplished by using SCTP, you > should use it. There is no need to reinvent the wheel, there is even > lesser need to reinvent TCP and to turn TCP into a worse SCTP. > > Perhaps you should focus more on the problem you want to solve instead > of dealing with more or less useless analogies. Let me repeat one more time, I am not trying to solve any issue using the TCP reset mechanism. I've never said that, have I? I am not trying to propose a TCP reset mechanism. I want to hear people's comment about such a mechanism. In fact, I have strong reservation about the SCTP TSN/SSN reset mechanism. And I believe what people have said against TCP sequence number reset applies to SCTP TSN/SSN reset. Each stream in an SCTP association is just like a TCP connection. As many folks have commented, resetting TCP sequence number does not sound right. The same thinking applies well to the SCTP case. -- K. Poon. ka-cheong.poon at oracle.com From ka-cheong.poon at oracle.com Wed Mar 30 22:05:30 2011 From: ka-cheong.poon at oracle.com (Kacheong Poon) Date: Thu, 31 Mar 2011 13:05:30 +0800 Subject: [e2e] SCTP TSN/SSN reset In-Reply-To: <4D93448E.6000502@oracle.com> References: <4D8AF82F.8060100@oracle.com> <20110324133849.GC19194@locust.cns.vt.edu> <4D8B75F2.2080107@oracle.com> <4D8BC9EF.4060207@isi.edu> <4D8C21CC.9090608@oracle.com> <4D8C24E4.6060401@isi.edu> <4D8C32C7.8060904@oracle.com> <4D8F4DA9.5000803@web.de> <4D905D5A.2010208@oracle.com> <4D92C15D.7050602@oracle.com> <4D9324B3.2090706@web.de> <4D93448E.6000502@oracle.com> Message-ID: <4D940B9A.4010602@oracle.com> I guess I should summarize the confusion (!) I created on this list by asking a wrong question. No one on the list thinks that TCP sequence number reset is a good idea. Although IMHO the same comments apply well to SCTP, I cannot say for sure that folks who had commented think the same. I'd like to ask those folks who are interested in SCTP to go to the TSVWG mailing list to voice your concern if you agree with me. And if you happen to be attending the IETF meeting (I am not), please voice your concern in the TSVWG session also. It seems that they will vote on concluding the draft and make it a PS. On 03/30/11 10:56 PM, Kacheong Poon wrote: > Let me repeat one more time, I am not trying to solve any issue > using the TCP reset mechanism. I've never said that, have I? > I am not trying to propose a TCP reset mechanism. I want to hear > people's comment about such a mechanism. In fact, I have strong > reservation about the SCTP TSN/SSN reset mechanism. And I believe > what people have said against TCP sequence number reset applies to > SCTP TSN/SSN reset. Each stream in an SCTP association is just > like a TCP connection. As many folks have commented, resetting > TCP sequence number does not sound right. The same thinking applies > well to the SCTP case. -- K. Poon. ka-cheong.poon at oracle.com From davehart at gmail.com Thu Mar 31 00:06:37 2011 From: davehart at gmail.com (Dave Hart) Date: Thu, 31 Mar 2011 07:06:37 +0000 Subject: [e2e] SCTP TSN/SSN reset In-Reply-To: <4D940B9A.4010602@oracle.com> References: <4D8AF82F.8060100@oracle.com> <20110324133849.GC19194@locust.cns.vt.edu> <4D8B75F2.2080107@oracle.com> <4D8BC9EF.4060207@isi.edu> <4D8C21CC.9090608@oracle.com> <4D8C24E4.6060401@isi.edu> <4D8C32C7.8060904@oracle.com> <4D8F4DA9.5000803@web.de> <4D905D5A.2010208@oracle.com> <4D92C15D.7050602@oracle.com> <4D9324B3.2090706@web.de> <4D93448E.6000502@oracle.com> <4D940B9A.4010602@oracle.com> Message-ID: On Thu, Mar 31, 2011 at 05:05 AM, Kacheong Poon wrote: > I guess I should summarize the confusion (!) I created on > this list by asking a wrong question. It seems only appropriate given the "confusion" was created by your attempt to deceive your audience and your failure to disclose the axe you were grinding. > Although IMHO the same comments apply well to SCTP, I cannot > say for sure that folks who had commented think the same. You really ought to give up defending your mistake and start over. TCP is not capable of carrying multiple distinguished streams as part of a single connection and so is not an appropriate analogy. IMO nothing said about the utility of resetting TCP sequence numbers within an established connection can be directly applied to SCTP, simply because SCTP uses transport sequence numbers as initial stream sequence numbers, which use can not be modeled by a TCP analogy. You might as well be arguing that retractable landing gear on airplanes are useless because your car has never once needed to retract its gear. Cheers, Dave Hart From ka-cheong.poon at oracle.com Thu Mar 31 01:16:33 2011 From: ka-cheong.poon at oracle.com (Kacheong Poon) Date: Thu, 31 Mar 2011 16:16:33 +0800 Subject: [e2e] SCTP TSN/SSN reset In-Reply-To: References: <4D8AF82F.8060100@oracle.com> <20110324133849.GC19194@locust.cns.vt.edu> <4D8B75F2.2080107@oracle.com> <4D8BC9EF.4060207@isi.edu> <4D8C21CC.9090608@oracle.com> <4D8C24E4.6060401@isi.edu> <4D8C32C7.8060904@oracle.com> <4D8F4DA9.5000803@web.de> <4D905D5A.2010208@oracle.com> <4D92C15D.7050602@oracle.com> <4D9324B3.2090706@web.de> <4D93448E.6000502@oracle.com> <4D940B9A.4010602@oracle.com> Message-ID: <4D943861.5060604@oracle.com> On 03/31/11 03:06 PM, Dave Hart wrote: > On Thu, Mar 31, 2011 at 05:05 AM, Kacheong Poon wrote: >> I guess I should summarize the confusion (!) I created on >> this list by asking a wrong question. > > It seems only appropriate given the "confusion" was created by your > attempt to deceive your audience and your failure to disclose the axe > you were grinding. I never tried to "deceive" anyone. I merely posted a question without making an assertion. If you don't agree with my TCP analogy and think that it is incorrect, it is fine. But it does not mean that I "deceive" you by making such an analogy. I don't know what your intention is by saying that I "deceive" the folks on this list. But I don't believe it is a justified accusation. And I don't think this kind of statement is appropriate in this mailing list. >> Although IMHO the same comments apply well to SCTP, I cannot >> say for sure that folks who had commented think the same. > > You really ought to give up defending your mistake and start over. > TCP is not capable of carrying multiple distinguished streams as part > of a single connection and so is not an appropriate analogy. IMO > nothing said about the utility of resetting TCP sequence numbers > within an established connection can be directly applied to SCTP, > simply because SCTP uses transport sequence numbers as initial stream > sequence numbers, which use can not be modeled by a TCP analogy. You > might as well be arguing that retractable landing gear on airplanes > are useless because your car has never once needed to retract its > gear. You have your opinion and I have my opinion. It is fine that you don't agree with my opinion. But it does not mean that I need to give up my opinion and agree with yours. An SCTP stream is similar to a TCP connection. This is my opinion. Whether you agree with it or not is up to you. My opinion is that there is no need to have a transport level TSN/SSN reset mechanism in SCTP. It is just moving what can be and should be done in app layer protocol down to the transport layer. It is making the transport unnecessarily complex without adding much value. It is not a good design approach. And resetting SSN is similar to resetting TCP sequence number. This is my opinion and whether you agree with it or not is up to you. But it is also up to me to have my opinion. There is no reason I need to give up mine. I've never ask you to give up yours, have I? -- K. Poon. ka-cheong.poon at oracle.com From davehart at gmail.com Thu Mar 31 03:15:15 2011 From: davehart at gmail.com (Dave Hart) Date: Thu, 31 Mar 2011 10:15:15 +0000 Subject: [e2e] SCTP TSN/SSN reset In-Reply-To: <4D943861.5060604@oracle.com> References: <4D8AF82F.8060100@oracle.com> <20110324133849.GC19194@locust.cns.vt.edu> <4D8B75F2.2080107@oracle.com> <4D8BC9EF.4060207@isi.edu> <4D8C21CC.9090608@oracle.com> <4D8C24E4.6060401@isi.edu> <4D8C32C7.8060904@oracle.com> <4D8F4DA9.5000803@web.de> <4D905D5A.2010208@oracle.com> <4D92C15D.7050602@oracle.com> <4D9324B3.2090706@web.de> <4D93448E.6000502@oracle.com> <4D940B9A.4010602@oracle.com> <4D943861.5060604@oracle.com> Message-ID: On Thu, Mar 31, 2011 at 08:16 AM, Kacheong Poon wrote: > On 03/31/11 03:06 PM, Dave Hart wrote: >> On Thu, Mar 31, 2011 at 05:05 AM, Kacheong Poon wrote: >>> >>> I guess I should summarize the confusion (!) I created on >>> this list by asking a wrong question. >> >> It seems only appropriate given the "confusion" was created by your >> attempt to deceive your audience and your failure to disclose the axe >> you were grinding. > > I never tried to "deceive" anyone. ?I merely posted a > question without making an assertion. Your original message and the great majority of the traffic carried the subject line "TCP sequence number reset" and began with the text: > Just want to get some opinion from the list members about an > idea proposed in an IETF draft. ?The equivalent idea when > applied to TCP is sequence number reset. ?The idea is that > assuming an application can access TCP sequence number with > each byte of data, an app is allowed to reset the TCP sequence > number when it wants to. The message failed to point to the draft in question, and in fact failed to mention SCTP at all. That omission may have been well-intentioned from your perspective, from mine it was deceptive to omit important relevant information. I would expect you to have recognized that the SCTP proposal is not equivalent to the TCP straw-man proposal (because TCP's sequence number is used more narrowly and is not available to applications) and refrained from claiming it is. >?If you don't > agree with my TCP analogy and think that it is incorrect, > it is fine. ?But it does not mean that I "deceive" you by > making such an analogy. ?I don't know what your intention > is by saying that I "deceive" the folks on this list. My intention is to facilitate open, honest communication and a mature exchange of ideas, and to discourage intentional omission of relevant information. > But I don't believe it is a justified accusation. ?And > I don't think this kind of statement is appropriate in > this mailing list. You may be right, if you interpret my claim that you "attempt to deceive" as an ad-hominem attack. I consider it a criticism of your actions here, and not upon your person. >>> Although IMHO the same comments apply well to SCTP, I cannot >>> say for sure that folks who had commented think the same. >> >> You really ought to give up defending your mistake and start over. >> TCP is not capable of carrying multiple distinguished streams as part >> of a single connection and so is not an appropriate analogy. ?IMO >> nothing said about the utility of resetting TCP sequence numbers >> within an established connection can be directly applied to SCTP, >> simply because SCTP uses transport sequence numbers as initial stream >> sequence numbers, which use can not be modeled by a TCP analogy. ?You >> might as well be arguing that retractable landing gear on airplanes >> are useless because your car has never once needed to retract its >> gear. > > > You have your opinion and I have my opinion. ?It is fine > that you don't agree with my opinion. ?But it does not mean > that I need to give up my opinion and agree with yours. Believe it or not, that was friendly advice. I have taken no position on the SCTP sequence number proposal and am inclined to agree with your belatedly-apparent position. Cheers, Dave Hart From detlef.bosau at web.de Thu Mar 31 04:09:03 2011 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 31 Mar 2011 13:09:03 +0200 Subject: [e2e] TCP sequence number reset In-Reply-To: <4D93448E.6000502@oracle.com> References: <4D8AF82F.8060100@oracle.com> <20110324133849.GC19194@locust.cns.vt.edu> <4D8B75F2.2080107@oracle.com> <4D8BC9EF.4060207@isi.edu> <4D8C21CC.9090608@oracle.com> <4D8C24E4.6060401@isi.edu> <4D8C32C7.8060904@oracle.com> <4D8F4DA9.5000803@web.de> <4D905D5A.2010208@oracle.com> <4D92C15D.7050602@oracle.com> <4D9324B3.2090706@web.de> <4D93448E.6000502@oracle.com> Message-ID: <4D9460CF.80401@web.de> On 03/30/2011 04:56 PM, Kacheong Poon wrote: > > SCTP TSN/SSN reset. Each stream in an SCTP association is just > like a TCP connection. As many folks have commented, resetting > TCP sequence number does not sound right. The same thinking applies > well to the SCTP case. > > > As I stated ago, I'm not quite familiar with SCTP. However, you could find out whether the TCP related comments relate to SCTP in the same way by simply summarizing the abstraction provided by SCTP. Because I'm an SCTP newbie, I'm eager to learn ;-) So, you could simply start by summarizing the abstraction provided by SCTP - and we will see, what we can achieve. Detlef -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de ------------------------------------------------------------------