Talk:Transport layer

message: 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)
replies: text: 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)
thread_title:  Ports in transport layer? 

message: 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)
replies: text: 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)
thread_title:  SMB as a transport layer 

message: 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)
replies: text: 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)
thread_title:  iSCSI as a transport layer 

message: 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)
thread_title:  GRE 

message: 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)
replies: text: 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)
replies: text: 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)

text: PS: Whoops, actually, we already have both stacks in the article. Kbrose (talk) 01:36, 9 February 2010 (UTC)
thread_title:  OSI x TCP/IP 

message: 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)
thread_title:  Transport vs. Application protocol 

message: 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)
thread_title: Move discussion in progress

message: 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)
thread_title:  include Hole Punching protocols 

message: 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)
replies: text: Presumably you're referring to the UDP-based Data Transfer Protocol. Guy Harris (talk) 17:37, 1 June 2016 (UTC)
thread_title:  UDT 

message: 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:
—Cxw (talk) 19:30, 26 March 2018 (UTC)
replies: text: Would the positive connotations of green then also be inappropriate? Guy Harris (talk) 19:55, 26 March 2018 (UTC)
replies: text: 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)

text: 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)
replies: text: I would rather have no color than the red, so I would be OK with that. —Cxw (talk) 13:17, 24 April 2018 (UTC)
thread_title:  Proposal to remove red from Comparison table 

message: > 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)
replies: text: 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)
thread_title:  HTTP/3 is UDP, not TCP