Talk:Transport layer

Ports in transport layer?

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

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

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

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

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

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

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?"

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

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 (talk • contribs) 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)

include Hole Punching protocols

Hole_punching_(networking) should be included in Transport Layer because its a unique way of addressing that receives from addresses that are not where a connection went out to. This may be the only practical way to move bytes directly between Network_address_translation addresses. 97.89.100.56 (talk) 23:45, 31 August 2015 (UTC)

UDT

UDT is a fairly robust and is becoming used in the industry. Shouldn't it be added? — Preceding unsigned comment added by 84.108.67.138 (talk) 08:45, 1 June 2016 (UTC)

Presumably you're referring to the UDP-based Data Transfer Protocol. Guy Harris (talk) 17:37, 1 June 2016 (UTC)

Proposal to remove red from Comparison table

I think the negative connotations of the default red color in the comparison table are not deserved. For example, UDP shouldn't be marked red just because it doesn't support reliable transport --- it's not supposed to do so! I propose the following (transcluded), which just removes the red:

Feature	UDP	UDP-Lite	TCP	Multipath TCP	SCTP	DCCP	RUDP
Packet header size	8 bytes	8 bytes	20–60 bytes	50–90 bytes	12 bytes	12 or 16 bytes	14+ bytes
Typical data-packet overhead	8 bytes	8 bytes	20 bytes	?? bytes	44–48+ bytes	12 or 16 bytes	14 bytes
Transport-layer packet entity	Datagram	Datagram	Segment	Segment	Datagram	Datagram	Datagram
Connection-oriented	No	No	Yes	Yes	Yes	Yes	Yes
Reliable transport	No	No	Yes	Yes	Yes	No	Yes
Unreliable transport	Yes	Yes	No	No	Yes	Yes	Yes
Preserve message boundary	Yes	Yes	No	No	Yes	Yes	Yes
Delivery	Unordered	Unordered	Ordered	Ordered	Ordered / Unordered	Unordered	Unordered
Data checksum	Optional	Yes	Yes	Yes	Yes	Yes	Optional
Checksum size	16 bits	16 bits	16 bits	16 bits	32 bits	16 bits	16 bits
Partial checksum	No	Yes	No	No	No	Yes	No
Path MTU	No	No	Yes	Yes	Yes	Yes	?
Flow control	No	No	Yes	Yes	Yes	No	Yes
Congestion control	No	No	Yes	Yes	Yes	Yes	?
Explicit Congestion Notification	No	No	Yes	Yes	Yes	Yes	?
Multiple streams	No	No	No	No	Yes	No	No
Multi-homing	No	No	No	Yes	Yes	No	No
Bundling / Nagle	No	No	Yes	Yes	Yes	No	?

—Cxw (talk) 19:30, 26 March 2018 (UTC)

Would the positive connotations of green then also be inappropriate? Guy Harris (talk) 19:55, 26 March 2018 (UTC)

Fair question - I thought about that myself. Some kind of color difference makes it easier to read. (Similarly, I have no issue with the "Optional" cells being light green.) Perhaps Template:Yes2 labelled "Yes"? Purge and you should see that in one row of the above. —Cxw (talk) 01:07, 28 March 2018 (UTC)

I think we should stick with standard cell coloring or remove cell coloring altogether. The protocols that have more green generally do have more features. Are they better? Depends on the application. ~Kvng (talk) 14:07, 30 March 2018 (UTC)

I would rather have no color than the red, so I would be OK with that. —Cxw (talk) 13:17, 24 April 2018 (UTC)

HTTP/3 is UDP, not TCP

> TCP is used for many protocols, including HTTP web browsing ...

With HTTP/3 (Draft but already used) it is not true anymore.

--mj41 (talk) 07:56, 7 October 2019 (UTC)

Given that I read your comment over TCP, it most definitely is still true. It might not be the only transport used for HTTP browsing, but only if HTTP/3 completely replaces HTTP and HTTP/2 will it be the case that TCP is no longer used for HTTP Web browsing. Guy Harris (talk) 08:08, 7 October 2019 (UTC)