Talk:Stream Control Transmission Protocol

does anyone really use this?

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:

Userland adds latency
It adds another layer -> even more latency
Require linking of a library for all apps to add ability, which leads to it's own set of problems and potential compatibility conflicts
UDP & TCP use a weaker checksum algorithm and shorter checksum
iptables, etc. filter by UDP port, not an upper layer protocol on that
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)
Userland multi-timer support hasn't been the greatest from what I've seen
Would require upper layer protocol modifications for a server to handle both UDP & "SCTP"/UDP on the same port
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]

Packet Structure Tables

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

The tables are fixed-width by pixels: this is a no-no, especially for a site like Wikipedia. Use relative sizes.
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.
The tables are encapsulated in another table. This is entirelly unnecessary and merely strains browsers (and therefore users' computers) unnecessarily.
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.
The plus sign (+) is not a proper heading.
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]

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
I welcome a better solution than using 25% per column.
This is to right align them. Not doing so wastes a lot of space to its right.
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.
Um, ok...
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]