Talk:Stream Control Transmission Protocol

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Definition of "Message"[edit]

What is a "Message" in this given context? --194.113.59.80 (talk) 09:47, 5 August 2008 (UTC)[reply]

Please reword[edit]

"All bytes sent in a TCP connection must be delivered in that order, which requires that a byte transmitted first must safely arrive at the destination before a second byte can be processed even if the second byte manages to arrive first. If an arbitrary number of bytes are sent in one step and later some more bytes are sent, these bytes will be received in order, but the receiver can not distinguish which bytes were sent in which step. SCTP in contrast, conserves message boundaries by operating on whole messages instead of single bytes. That means if one message of several related bytes of information is sent in one step, exactly that message is received in one step."

This paragraph is vague and confusing, and I do know something about network protocols. I think the first sentence is saying that TCP cannot gracefully handle byte reordering of its packet payloads. The second sentence seems to be more confusing explanation of this point. I don't understand the meaning of the third sentence at all ("operating on" whole messages vs. single bytes? How is it "operating"? What is a "message" in this context?) In the fourth sentence, what does "related bytes" mean? If the checksum on a TCP packet checks out, its payload is received in "one step" as well. I'm guessing that the SCTP bytestream is further semantically divided into messages, but I can't tell for sure from what is written in this paragraph. - 74.112.174.192 15:16, 5 February 2007 (UTC)[reply]

TCP stream reassembly[edit]

The page currently states "TCP ensures byte order by conceptually assigning a sequence number to each byte sent and ordering these bytes based on that sequence number when they arrive.", but I find this claim very awkward and misleading: TCP does not reorder bytes, it reorders the payloads of separate packets. As I understand it, each packet contains the sequence number of the last byte it contains, which simply used as the basis for reordering. Furthermore, the link to the article 'byte order' is entirely irrelevant as the target article talks about Endianness which has nothing to do with stream reassembly.

I made an edit hoping to be more clear, but it was reverted by User:Cburnett with the message "TCP packet data cannot be randomly rearranged and be accepted as "good", therefore the data in a packet must be in the same byte order as sent". Am I missing the point? Obviously TCP cannot randomly reorder bytes or payloads. The whole issue is about guaranteeing that the individual packet payloads are reassembled in the order they were initially written to the stream. -- intgr 20:01, 13 April 2006 (UTC)[reply]

Byte order requires packet order. By ensuring packet order only, I could scramble the bytes within a packet and still satisfy "packet order". If TCP had no error checking built-in then it would indeed be packet order only. However, since it includes a checksum then it ensures (to a certain degree) the bytes within the packets are in proper order. Byte order is more specific than packet order. If you want to say both, great, but don't make it more broad or less-encompassing than it really is.
You say "Obviously TCP cannot randomly reorder bytes" but there's more involved than just TCP. Theoretically, there's nothing saying that a device can't scramble bytes as it routes data. It would be a horrible device and no one would buy it — whom has no malicious intent anyway — but there's nothing TCP can do to stop such a device except ensure byte order by utilizing an error correction. TCP does more than ensure packet order. Cburnett 01:58, 12 May 2006 (UTC)[reply]
First, the term "byte order" is accepted in the computer science community to define endianness, not the ordering of bytes in a stream; it's misleading to use this term in the literal sense.
As for guaranteeing the ordering of bytes, the fact that checksums also verify the ordering of bytes is a side-effect of error-free delivery, and entirely irrelevant to stream reconstruction - TCP cannot restore the proper ordering of the bytes in the way it can reorder individual payloads. Cases where packets arrive in different order than they were sent is common in IP networks, thus TCP takes care of this gracefully by reordering the payloads. Cases where the contents of payloads is tampered with (reordering the bytes or otherwise) is a delivery error, thus the packets are dropped and have to be retransmitted; this is irrelevant in the context where the reassembly features of the protocols are compared. -- intgr 13:13, 12 May 2006 (UTC)[reply]
We can rewrite it "ensure the order of bytes" if there's a terminology issue. Rewording can remove the ambiguity of "byte order". Doing so I have zero problem with.
We are not talking about reconstruction, but "what does TCP offer?" The answer: a sequential order of bytes. The exact same order of bytes going into the stack is the exact same order of bytes coming out of the stack. TCP doesn't deliver packets to the receiver but a stream of bytes. As far as the application is aware: packets do not exist. Neither is it aware of timers, sequence numbers, nor fragmentation. It sends some data to a host & port. Sends some more data. Sends even more data and then closes the socket. The application doesn't worry about MTUs or fragmentation. All it cares about is byte 4 comes after byte 3 which comes after byte 2. And this is precisely what TCP provides. The fact that byte ordering is a "side-effect" of checksumming is irrelevant: checksumming is apart of TCP.
I have no problems rewording things. My only problem is to saying it ensures packet ordering when it really ensures byte ordering. If it didn't ensure byte ordering then scrambling packets would be ok. But it's not ok and so TCP does more than packet ordering which is byte ordering.
From an algorithmical point of view: sure, TCP only does packet ordering. Collect the fragments, slap them in order, and ship them up the stack when it can. It does no direct "ok, byte 3 goes here, byte 4 goes there, and byte 16 way over there" but indirectly by checksumming (your "side-effect").
At the end of the day, my data in the application is sent sequentially as a stream of bytes and is received sequentially as a stream of bytes. My application has no concept of packet ordering. It doesn't even know what it is. I can certainly introduce some concepts to increase optimization but that's not a requisite. Cburnett 19:35, 17 May 2006 (UTC)[reply]
After re-reading the paragraph in question, I now realize that it was not comparing reassembly of SCTP fragmented messages vs reassembly of TCP streams, but the ordering of delivered messages vs bytes from the application viewpoint, although the claim of TCP reordering bytes per se still seems awkward to me. I apologise for wasting your time, I'm going ahead and changing the 'byte order' part of the statement. -- intgr 09:57, 18 May 2006 (UTC)[reply]

does anyone really use this?[edit]

i notice this protocol is mentioned quite a lot in various wikipedia networking articles yet it doesn't even seem to be supported on windows! This would seem to indicate to me that its unlikely to be used much outside niche applications. Plugwash 22:36, 5 November 2005 (UTC)[reply]

I used this article. It was very helpful. I don't think that it's just important for niche applicatons. It might be much more important that you could imagine. Do you think protocols are just important when they are supportet by this windows? Up till now it is used in other environments. Maybe already if you make your next phone call - just in the background. By the way: do you know that windows was quite late with using the already established and important TCP/IP?
I am not very informed about what a topic in Wikipedia needs to get right of an own article. But I guess this one is okay. Micha. 10 February 2006

Good to know but i can't see how a protocol not supported by windows can gain any traction for end user apps. maybe for special networks where compatibility with clients using the standard desktop os isn't required but not for general use.

BTW i'm not arguing that this article should be far from it its just if this is a hardly used niche protocol it should be identified as such. Plugwash 01:02, 10 February 2006 (UTC)[reply]

While the RFC is 5 years old, realize that the TCP RFC has been out for 24 years. Considering how entrenched TCP is for most protocols...you gotta realize it'll take time to get used. It's a catch: if applications use it then SCTP will be tossed in the IP stack and used; if no applications use it then SCTP will just sit there and people have little motivation to develop it. Cburnett 16:30, 22 February 2006 (UTC)[reply]
Which is why UDP was such a good idea. It pushes the problems of reliable transport etc up into userland where additions are much easier than in the OS. Plugwash 19:08, 22 February 2006 (UTC)[reply]
Some reasons why not to do "SCTP" over UDP off the top of my head:
  1. Userland adds latency
  2. It adds another layer -> even more latency
  3. Require linking of a library for all apps to add ability, which leads to it's own set of problems and potential compatibility conflicts
  4. UDP & TCP use a weaker checksum algorithm and shorter checksum
  5. iptables, etc. filter by UDP port, not an upper layer protocol on that
  6. UDP has no protocol field in the header so that the data can be differentiated (thus a TFTP vs. "SCTP"/UDP packet can't be differentiated without some kind of analysis)
  7. Userland multi-timer support hasn't been the greatest from what I've seen
  8. Would require upper layer protocol modifications for a server to handle both UDP & "SCTP"/UDP on the same port
  9. You couldn't add "SCTP"/UDP support to existing protocols that use UDP because of the previous point
That enough? Cburnett 00:08, 24 February 2006 (UTC)][reply]
Yes, this protocol is extensively used in telecommunications. This is not the sort of thing you would see on a desktop PC although it would be useful if it was available on Windows. Almost every major telecommunications switch that deals with voice traffic will offer some form of SCTP implementation smyles 13:50, 24 February 2006 (UTC)[reply]
Well, I think there's plenty of non-telephony applications that would benefit from SCTP. But since you seem to be in the know, I'd like to throw some questions at you for curiosity's sake (and possibly to toss in the article) and quelling my ignorance in regard to telecom applications. What is SCTP used on other than IP/ethernet? Does SCTP play into Message Transfer Part at all? Are there SCTP <--> SS7 bridges? Are they common? Any idea of the penetration of SCTP into public telecom? Etc. :) Cburnett 19:08, 24 February 2006 (UTC)[reply]
I agree that a *lot* of other applications would work well with SCTP. As far as I'm aware, SCTP is used only on IP, although that could be IPv4 or IPv6. I've seen it carried over ethernet and FDDI. I would say that the most common use of SCTP was carrying MTP type traffic. After all, that was what it was designed to do. An adaptation protocol such as M2UA [1] is used to do this. SCTP<->SS7 bridges exist and are in common use, particularly in parts of carriers' networks that are pure signalling, carrying things like INAP or MAP. An example of this would be something like this [2] from Siemens (no relationship). I would think that most large public telecom carriers would have some kind of equipment like this around now. Any investment in new equipment would not tend to be old circuit switched kit. smyles 22:33, 6 March 2006 (UTC)[reply]
In the telephony world, sigtran in general, which includes SCTP, is finally having an impact. As Barrymyles said, adaptation layers allow traditional SS7 traffic to be carried over IP transports. The most common requirement being seen, in Europe at least, seems to be M3UA - MTP3 User Adaptation layer. That is, any traditional SS7 traffic that currently sits on top of MTP 3 can now be carried over SCTP: ISUP, TUP, NUP, SCCP and its users (TCAP, and hence MAP, INAP and CAP). IP to SS7 bridges are Signalling Gateways (SGs), and are becoming more and more prevalent, especially with emerging technologies like IMS, and Next Gen Networks (NGNs). SGs are needed to support legacy telephony equipment - HLRs, Prepaids, SMSCs, VM - in the NGN, allowing these non-IP capable boxes to use the cheap, in comparison to E1/T1 based trunk, transport provided by enterprise IP networks.
Typically, the interface between a traditional CS network and the newer PS network would involve signalling gateways to convert say ISUP into SIP, and media gateways to convert TDM voice bearers into RTP streams for transport across IP, allowing CS handsets to communicate with IP phones, or even CS-to-CS, with a cheaper transport in the middle.

Information about the status of this protocol in real-world deployments should be added to the article. -- Beland 19:47, 22 September 2007 (UTC)[reply]

Fast forward a few years. STCP still looks good on paper. Legacy telephone and SS7 along with it is being overrun by VoIP. Some refs indicated that SIP can be carried via STCP but that is not mentioned on Wikipedia or in RFC 3261; does anyone actually do this? www.sctp.org was last updated in 2004. What's going on? --Kvng (talk) 17:48, 15 July 2011 (UTC)[reply]

Packet Structure Tables[edit]

I have a few problems with the way the Packet Structure tables have been set up.

  1. The tables are fixed-width by pixels: this is a no-no, especially for a site like Wikipedia. Use relative sizes.
  2. The columns are not of equal width. This goes along with the relative sizes: set sizes for the columns, and let the browser determine the width of the table.
  3. The tables are encapsulated in another table. This is entirelly unnecessary and merely strains browsers (and therefore users' computers) unnecessarily.
  4. The tables are divided into 32 rows, representing 32 bits. When most of the fields are no smaller than a byte, this is incredibly unnecessary. It's just a waste of processing power for semantics.
  5. The plus sign (+) is not a proper heading.
  6. There is a simple solution to all of this, and I'm more than willing to do it: make them all as images. HTML tables are terrible.

—Kbolino 22:08, 7 March 2006 (UTC)[reply]

  1. You need to gather consensus on that one. List of South Park episodes had an oppose vote for featured list candidacy because tables were inconsistent width, therefore they required fixed width. Additionally, the columns were of relative width. Only the containing table had the width set
  2. I welcome a better solution than using 25% per column.
  3. This is to right align them. Not doing so wastes a lot of space to its right.
  4. Consistency is a Good Thing. Please provide proof that using 32 columns is sufficiently slow to warrant breaking consistency. All I have is your theoretical word on it. Considering the number of tables and nested tables I've used on some pages, I call royal bollucks on this point.
  5. Um, ok...
  6. Images require more bandwidth.
Additionally, packet parsing is a bit-level operation — not a byte-level operation. All RFCs and texts I've read that detail (bit-packed) protocols all use bit counts, not byte counts.
Let me get this straight. You want to sacrifice consistency and waste screen space while claiming too much processing time is being used for nested tables and 32 columns AND propose increasing the total page size drastically by inserted over a dozen large images??? Processing time is much cheaper than bandwidth. A nested table with 32 columns is trivial in DOM manipulation and screen rendering — downloading 16+ images is non-trivial for non-bandwidth users.
If you can suggest a way to do table right alignment without a nested table (and still using class=wikitable) then I'm all ears. I am going to revert the bit -> byte usage since your concern of browser speed is moot (until you prove otherwise) and to maintain consistency not only within the page but amongst sources (primary sources — RFCs — and secondary sources — texts).
You'll also have to excuse my crass tone here — I'm all for discussion, really — but your position isn't all that strong and revert warring is nothing short of annoying and pointless.
This discussion has also made me realize all the chunk tables were wasting space so I'm going to go ahead and right justify those as well. Cburnett 00:07, 8 March 2006 (UTC)[reply]
Well, let me clarify then.
  • Percent sizes are relative. You can specify that all tables occupy a certain percentage of the visible width, and the browser will (usually) obey this to an extent. Mind you, this is not quite the same as em-spacing, which adjusts proportionally to the size of the font—something users, especially ones who have a harder time seing, are likely to do. Oh, and at 800x600, all of the tables occupy different widths. In fact, by 1024x768, they're still not all even, though it's much improved.
  • You are breaking the table into 33 columns and specifying width="25%" for abstract (read: colspan > 1) columns, which is why they don't actually end up being equal width. You have to set the width for each of the actual columns.
  • I understood completely why you divided into 32 columns. It would make perfect sense if the rendering wasn't client-side. But it is, and this is wasteful. No more than the total number of columns necessary should be used. For the DATA chunk table, for instance, this would 6 (not including the left column).
  • Your "Um, ok..." response doesn't negate the fact that the plus sign is not a valid column heading. It carries no meaning.
  • The hyphen-minus (-) is not the proper character to represent ranges of values, such as between bits. The proper character is the en dash (–); if you paid any attention to my edits, you would've noticed.
  • You're somewhat right about the images; it was merely a suggestion. Anyone using Wikipedia with a low-bandwidth connection is pretty much stuck waiting for most pages. FYI, I can make PNG images pretty damn small with the right tools.
  • Right alignment is not standard. Waste space. It's digital space, not paper. Jumbling everything together just confuses the reader—especially if the table takes up three-fourths of the page at lower resolutions. And yeah, there are two ways to do right alignment: direct attribute align="right" (not recommended) or style="float: right" (preferable) in the <table> tag.
  • And finally, as a C programmer, I know what programming sockets is like. Which means I've parsed packets. And it, like all data processing, is done by transferring bytes. That's why packets end a certain way or specifically specify their own sizes. If all processing was bit level, this usually wouldn't be necessary. But data is moved to and from memory, on and off the registers, etc. in bytes or groups of bytes. The data structure is bit-level, but the processing is byte-level. Don't believe me? Fine, don't take my word for it. See recv and send from the sys/socket.h definition.
  • [Addendum: you can call it whatever the hell you want, but it's not bullocks. Nested tables require separate memory for each table, and are processed individually. More columns = same deal. I'm on a sufficiently powerful machine now, but it's not all I use. And other people use older, slower computers too. Considering them is just as important as considering users with low bandwidth.]
Don't get an attitude with me. I changed one table, not all of them. I took into account what little you left on your edit description when I reverted the table, which is more than you did.
—Kbolino 20:48, 9 March 2006 (UTC)[reply]
Yowzers, this conversation is forking so fast I'm not sure where to begin.
Added a table and having 33 columns (most colspan'ed) is trivial to render. Again, I demand proof that it's such a problem to break consistency with every other RFC & text. I don't think you'll ever find any. I also put less faith in your evaluation when you talk of performance and adding 16 decent sized images in the same argument. It just doesn't make sense.
Besides, if you really cared about performance...there are so many other fish on WP to fry it's not even funny.
Next time — and before you start linking in references — you might want to read what I said first and respond to that. I said "packet parsing is a bit-level operation — not a byte-level operation" (emphasis added since you missed it the first time). I never said anything about memory copying, data transfer, or packet lengths. I said parsing. You can't parse IP, TCP, or SCTP without getting down to the bit level (if your cup of tea is masking and shifting or masking and testing against the mask — it doesn't matter as its all bit-level). You're arguing against a straw man on that one, not me.
The rest isn't worth risking further forking. Cburnett 01:24, 10 March 2006 (UTC)[reply]
You're right, there are other fish to fry on Wikipedia. But there are only a few things I care about, so I only puruse those subjects. I came across this article, so that's why I'm here. I'm going to leave the bits-bytes issue alone. It's pointless, and I can tell you know what you're doing, so let's leave it at: the tables are good in bits. Parsing is a separate issue.
The issue that's important is the semantics behind them. The point is, though there are indeed 32 bits in four bytes, the data structures aren't actually using all one-bit divisions. The apperance of a table that uses the minimum number of physical columns and a table that uses 32 columns for semantics is the same. The rendering cost, however, is not. That's my point. I made a mistake in converting to bytes, and for that I apologize. I even corrected my mistake in labelling, though reducing the semantic divisions to the minimum. This isn't violating any precedents, it's optimizing.
The only fork is my discussion about dashes, which still relates to my original purpose. In my previous response, I was addressing all of the points you brought up in your first response and I in mine. If you would prefer that I do not address all of your points, don't make them. Do not accuse me of forking when I have not ventured from the original purpose. I may be forking from the issue upon which you and I have fixated, but that's not the only issue at hand here.—Kbolino 03:10, 10 March 2006 (UTC)[reply]
Optimization isn't optimization when you change the problem: it's changing the problem. If you want to do real optimization by reducing the columns that are unused (such as 4 columns in the first table) while retaining the parameters of the table....then go for it. It would make consistent width columns easier. But if you want to redefine the tables (which you've been doing)...well you can see my fervor against that.
On a side note, I'd be inclined to believe that a browser doesn't render 32 columns (I guarantee it doesn't represent 32 of them in the DOM tree). Browser optimzation to recognize only 4 rendered columns wouldn't be hard. But I really digress. Cburnett 05:56, 10 March 2006 (UTC)[reply]
I hadn't considered the possibility that the browser did its own optimizations. It makes sense, and you're absolutely right about the DOM tree (at least, so says the DOM inspector). I rewrote the tables to appease all of my concerns, not just the columnar one. I really have more than lost interest in furthering this argument, so I'll just leave it be.—Kbolino 04:04, 12 March 2006 (UTC)[reply]

SCTP association failure[edit]

As a long term telephony (SS7) person, seeing sigtran becoming more and more requested by major operators, I have a slight concern about the speed of detection of link failures, which doesn't seem to be discussed here. SCTP speeds up link failure discovery when compared with TCP, thanks to the heartbeats, but the algorithm used to determine link failure is identical to that used in TCP. As a result of that, with RFC stated defaults, it's possible for a link to be down for (if memory serves, not got the RFC in front of me) 2 or 3 seconds (RTTMIN==1000 ms, retransmit attempts==2?); compare that with tradition TDM based SS7 signalling, with FISUs going back and forth constantly, and link failure detected in milliseconds. 3 seconds outage on a typical SCP (prepaid, VPN, toll-free), or SMSC could, potentially, result in thousands of lost, or at least delayed, messages.

Not sure of the point of this rambling, but it's something I'm concerned about, and am curious to see other people's opinions.

Comparison table with TCP and UDP[edit]

Is the comparison table in Transport_layer#Transport_protocol_comparison_table really correct? Now SCTP seemes to be equivalent to TCP. Please add rows to the table that pinpoints the major differences. Mange01 07:54, 27 June 2007 (UTC)[reply]

As things turned out, it was Mange01 who fixed this problem in July 2007. Nice work. CWC 08:43, 10 March 2008 (UTC)[reply]

Maybe merge this section with Transport_layer#Comparison_of_TCP.2FIP_transport_protocols? It would feel more ‘neutral’ to me if the comparison of the different protocols were on a different page than on one of the compared protocols’. kess (talk) 19:07, 20 May 2009 (UTC)[reply]

 Done --Kvng (talk) 15:12, 29 November 2010 (UTC)[reply]

Proper nouns[edit]

Stream Control Transmission Protocol is not a proper noun as far as I believe and from the guidelines in WP:MOS. 87.254.89.197 (talk) 01:51, 1 March 2009 (UTC)[reply]

It is a proper noun. It refers to a unique transport protocol. Transport protocol is not a proper noun because it refers to a class of protocols and can be preceded by any or some. Stream Control Transmission Protocol cannot be preceded by any or some. If you are the editor walking through all of the computing and telcom pages removing the caps from all of the proper nouns such as this, please stop. — Dgtsyb (talk) 16:54, 1 March 2009 (UTC)[reply]

DCCP[edit]

DCCP appears exactly once in the article as a column heading in the transport control protocol. DCCP appears to accomplish some of the same things as SCTP. Some discussion of DCCP comparing and contrasting the two in the article would be helpful --Kvng (talk) 03:46, 16 May 2009 (UTC)[reply]

Comparison between transport layers[edit]

There are two identical criterias: Reliable transport Unreliable transport —Preceding unsigned comment added by 212.154.22.58 (talk) 08:36, 18 May 2009 (UTC)[reply]

No, they are not identical: and SCTP is the only one listed that can provide both (either). — Dgtsyb (talk) 13:20, 18 May 2009 (UTC)[reply]

"message-oriented" versus "transaction-oriented"[edit]

The term "transaction" is common in the realm of databases and possibly memory systems where a set of changes must be made "atomically"--that is, all or nothing--to maintain consistency. I do not believe this term is appropriate in networking. In networking a more essential distinction is that between "streams" and "messages". In this article I prefer the term "message-oriented" over "transaction-oriented". IOLJeff (talk) 21:15, 3 July 2009 (UTC)[reply]

Simpler than UDP?[edit]

The Packet Structure section states "SCTP packets have a simpler basic structure than TCP or UDP packets." OK, TCP arguably, but UDP? UDP has 5 fields including the data payload. Even a single chunk SCTP packet has 8. I'm removing the reference to UDP, though if anybody thinks this is a goof feel free to reinstate it. Jonathan. —Preceding unsigned comment added by 86.216.134.185 (talk) 14:34, 21 February 2010 (UTC)[reply]

Good catch. (I'm embarrassed I didn't notice that.) Thanks, CWC 18:24, 21 February 2010 (UTC)[reply]

UDP doesnt guarantee reliability or in-sequence arrival[edit]

You say as the first paragraph: "In computer networking, the Stream Control Transmission Protocol (SCTP) is a Transport Layer protocol, serving in a similar role as the popular protocols Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). It provides some of the same service features of both, ensuring reliable, in-sequence transport of messages with congestion control. It seems that you're stating that UDP allows in-sequence transport because you say "serving in a similar role as ...TCP and UDP. It provides some of the same service features of both:....reliable, in-sequence transport".

UDP is not reliable nor guarantees in-sequence transport.—Preceding unsigned comment added by Dwilches (talk • contribs) 21:29, 27 April 2010

Good point. AFAIK the only feature SCTP has in common with UDP is preserving message boundaries. I've changed the lede accordingly. Thanks, Dwilches. CWC 03:16, 28 April 2010 (UTC)[reply]

References[edit]

The external links section was full of reference type items. This would be a good resource for someone who wants to improve the article or add citations. I don't think these comply with WP:EL and I don't think these are of direct use to most readers. --Kvng (talk) 15:26, 29 November 2010 (UTC)[reply]

I don't see any problem with any of these links. They are certainly not spam. Also, the transport comparison was meant to highlight SCTP's differences from other transport protocols and I believe should be retained here. I have reverted those changes. Can we please discuss more. — Dgtsyb (talk) 02:23, 30 November 2010 (UTC)[reply]
The primary purpose of the External links section is described in WP:ELYES. The external links section is long and, in my opinion has a WP:NOTLINK problem. But indeed none of the links appear to violate WP:ELNO. We do need to improve the EL section. Ideally many of the links would be repurposed as references. Apparently we have to do this incrementally not boldly. --Kvng (talk) 14:32, 30 November 2010 (UTC)[reply]
The article is not a mere list of links. Also, if it were to become a featured article, it would probably contain them all. Yes, they could be used in citations where possible, but this would require additional copy that is not yet in the article. One unfortunate reality of SCTP is that most of the textbooks that cover it simply regurgitate the RFCs, leaving web links as the only notable sources beyond the RFC itself. — Dgtsyb (talk) 02:27, 1 December 2010 (UTC)[reply]

External links modified[edit]

Hello fellow Wikipedians,

I have just modified one external link on Stream Control Transmission Protocol. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 23:50, 25 April 2017 (UTC)[reply]

Processing ordered messages out-of-order ?[edit]

The text states that ordering is optional, and that the receiver may choose to process ordered packets in an unordered fashion. The RFC states (https://tools.ietf.org/html/rfc4960#section-6.6) that ordered packets must be delivered to the upper layer in the correct order, which apparently contradicts this statement. Could somebody with better knowledge of SCTP verify this, and add a reference or remove the statement. RogierA7 (talk) 13:33, 9 December 2017 (UTC)[reply]

ssh[edit]

The referenced (and unreadable due to paywall) IEEE source doesn't seem to be related to the statement that ssh implements SCTP; I have found no references that it would nor found any instance of the string "sctp" in openssh source. I would like to see a direct reference to ssh changelog or source please. I doubt its correctness, to put it nicely. --grin ✎ 18:44, 13 August 2020 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Stream_Control_Transmission_Protocol&oldid=1205477627"