Talk:Transport layer

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computing / Networking (Rated B-class, Mid-importance)
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
B-Class article B  This article has been rated as B-Class on the project's quality scale.
 Mid  This article has been rated as Mid-importance on the project's importance scale.
Taskforce icon
This article is supported by Networking task force (marked as High-importance).
 

Ports in transport layer?[edit]

While the ports are crucial in TCP/UDP operation, it must be stressed that they deal with individual dialogs and their separation. So I think it is more appropriate to attribute the ports to the OSI session layer which is by its definition concerned with individual dialogs. There is not a clear correspondence between the ISO OSI and the TCP/IP reference models. This is one example of it where the transport layer in TCP/IP RM encompasses some of the session layer functionality from the ISO OSI RM. User:ALM_scientist 18:01, 6 November 2006

I agree, and I have adressed that problem in the latest change of the article. Mange01 17:09, 6 November 2006 (UTC)
Ports are just a multiplexing service provided by certain transport layer protocols. The transport layer just provides end-to-end communication services (word for word from TCP RFC definition of transport layer) and ports are one of these. Int21h (talk) 18:58, 30 July 2010 (UTC)

SMB as a transport layer[edit]

I don't know enough about how SMB is implemented, but its article claims that it is designed to work on top of NetBUI and TCP/IP, while this article claims it is a transport layer itself. This inconsistency should be fixed by someone who knows more about SMB than I.

SMB isn't a transport-layer protocol; it runs atop NetBEUI, NBT (which runs atop TCP/IP), and also runs directly atop TCP/IP. It's a request/response protocol (with some extra gunk for "transactions"), and is more like NFS or AFP than like the transport protocols listed here. I'll fix this. Guy Harris 22:47, 23 December 2005 (UTC)

iSCSI as a transport layer[edit]

I have the same question regarding iSCSI, which uses TCP ports 860 and 3260. RFC 3720 says that it "works on top of TCP". --Jerome Potts (talk) 04:37, 22 April 2008 (UTC)

A transport protocol can run over another transport protocol, but iSCSI is probably too application (storage) specific to qualify. Butlerm (talk) 09:17, 11 November 2008 (UTC)

I agree. A transport layer protocol can simply extend the services provided by another transport layer protocol, but iSCSI doesn't just provide extra services, it provides a entire storage infrastructure involving databases and other stuff. Int21h (talk) 19:11, 30 July 2010 (UTC)

GRE[edit]

Hello Fellas,

Can someone link the GRE to the TL? —Preceding unsigned comment added by 200.212.215.2 (talk) 16:33, August 28, 2007 (UTC)

GRE is more a tunnelling protocol, than a transport protocol. Butlerm (talk) 09:19, 11 November 2008 (UTC)

OSI x TCP/IP[edit]

Since there is no direct correspondance between the OSI and the TCP/IP models, this should be pointed out whevener there's a chance to. In fact, in my opinion, either separate articles should be created or different sections on each article should deal with specs and other information concerning the layers in each model stack. What I am saying is that the transport layer, for instance, has different characteristics depending on the model we're talking about: OSI or TCP/IP. Alan.rezende (talk) 20:17, 7 June 2008 (UTC)

I agree, while there is a close relationship between OSI and TCP/IP versions of an arch-typical "Transport Layer," they are different. Should both TCP/IP (Template:IPstack) and OSI templates (Template:OSI model) be displayed on this page? Might help to identify that there is a differentiation. Weylin.piegorsch (talk) 01:21, 9 February 2010 (UTC)
Yes, all correct. It's an ongoing struggle to find the best representation to make this clear. The easiest little step would indeed be to show both stacks. Kbrose (talk) 01:33, 9 February 2010 (UTC)
PS: Whoops, actually, we already have both stacks in the article. Kbrose (talk) 01:36, 9 February 2010 (UTC)

What is so different between the models? I think they're too close to call. The TCP model as defined in the Internet Protocol Suite by the TCP RFC simply defines the transport layer as providing "end-to-end communication services for applications." (RFC 1122, §1.1.3) I'd say that's pretty easy to sync with the OSI model.

Transport vs. Application protocol[edit]

Application, naming, routing, and management protocols shouldn't be considered transport protocols just because there is nothing else to place at layer 4. A transport protocol should minimally be capable of "transporting" a wide variety of higher level protocols. Butlerm (talk) 09:19, 11 November 2008 (UTC)

I think an easier definition is that transport layers simply provide end-to-end communication services. Int21h (talk) 19:12, 30 July 2010 (UTC)

Move discussion in progress[edit]

There is a move discussion in progress which affects this page. Please participate at Talk:Physical Layer - Requested move and not in this talk page section. Thank you. —RM bot 03:45, 19 October 2011 (UTC)

What is "NAT friendly?"[edit]

I have added citation needed tags to the "NAT friendly" row in the Comparison of transport-layer protocols section because the term "NAT friendly" is not defined on the linked page (NAT) and I suspect its inclusion may have been intended to promote some protocols over others without a neutral point-of-view. If citations cannot be found to back up these claims, then I suggest the row be removed as unverifiable.—Kbolino (talk) 18:20, 2 November 2011 (UTC)

See RFC 3235. — Dgtsyb (talk) 05:07, 3 November 2011 (UTC)
I have read through the cited material. Although it does a good job defining NAT friendly application-layer protocols (even the title is "Network Address Translator (NAT)-Friendly Application Design Guidelines"), it does very little to define what a NAT friendly transport-layer protocol is. The closest information of relevance I could find in that citation was:

Protocols other than TCP and UDP can work with Traditional NAT in many cases, provided they are not carrying addressing information. For NAPT implementations use of any protocols other than TCP and UDP will be problematic unless or until such protocols are programmed into the implementations.

This seems to contradict all of the Yeses which follow.... I have added not in citation given tags to the citations. In short, I tend to agree with Kbolino, that the row be removed unless good citations can be found.Gurnec (talk) 14:04, 21 October 2013 (UTC)
I've removed the "NAT friendly" row since it looks like no better sources could be found (and the one source that was found at best contradicted the all-Yes content of the row). gurnec (talk) 14:04, 17 December 2013 (UTC)

Article is TCP biased[edit]

The author of the article clearly thinks that TCP is the "correct" transport.

Transport layers are not obligated to provide byte stream semantics. In fact, TCP is one of the few that do. Most carry messages, such as SCTP or InfiniBand RC.

Reliability is also something that a Transport Layer *may* provide. TCP and SCTP do. UDP does not. InifiniBand RC does, UD does not. — Preceding unsigned comment added by Asomicait (talkcontribs) 19:06, 19 December 2013 (UTC)

I presume you're mainly objecting to the "Services" section. It says
There are many services that can be optionally provided by a transport-layer protocol, and different protocols may or may not implement them.
so it does indicate that byte-stream semantics and reliability are optional. However, at minimum, I agree that the part on byte-stream semantics should be rewritten so as not to describe either byte-stream or packet semantics as being better, and probably should be rewritten to describe both behaviors and be titled "byte or packet orientation" or something such as that. Guy Harris (talk) 19:28, 19 December 2013 (UTC)
Byte-stream semantics are not a "service" in the sense that, for example, reliable delivery is a "service". I've removed it from the list. Guy Harris (talk) 08:37, 20 December 2013 (UTC)