Talk:Traffic flow (computer networking)

Traffic flow types
The article needs a section to flesh this out a little:

65.161.188.11 (talk) 19:06, 15 March 2010 (UTC)
 * Terminal/host
 * Client/server
 * Thin client
 * Peer-to-peer
 * Server/server
 * Distributed computing


 * I'm not sure if the end points of a flow are as important as characteristics such as bandwidth, length, and burstiness. kgrr talk 14:19, 25 March 2010 (UTC)

Undeleted sections - citations NOT needed
The comment when much of the page was deleted was 'Deleted the unsupported nonsense. (No references provided after two months)'. But the page that replaced it was only about TCP flow, e.g. the 3 way handshake, which is better covered in the main page: Transmission Control Protocol. I'm not sure what is meant by 'unsupported nonsense', as all of this is basic stuff. Really too basic and uncontroversial to need citing.

I think the point about this page is it is NOT meant to be about TCP, but about all the uses of the term 'flow' in telecommunications and computer networking. This will include TCP, but there are lots of other protocols and even non-protocols, e.g. the use of flow when traffic flows are being modelled by a graph. Aarghdvaark (talk) 12:48, 25 March 2010 (UTC)


 * Ararghdvaark, You are right. The point about this page is traffic flows.  What I deleted had to do with routes.  Flows are not routes through networks.  Flows are groups of packets at one point in the network - at a router (e.g. Netflow) or at a monitoring point in the network (e.g. off of a span port in a network to a server running a tool)  Perhaps I was not specific about it in calling it nonsense.  I gave the TCP flows as an example, showing as to how it causes two flows.  I have now given more examples for other transport protocols - UDP and ICMP.  Other transport protocols behave the same.  Higher level protocols ride on top of transport protocols.   kgrr  talk 14:15, 25 March 2010 (UTC)


 * Hi kgrr . I think your examples are still too TCP/IP specific, for example in the main section 'Conceptual description' you say 'A flow can be uniquely identified by the following parameters within a certain time period: Source and Destination IP address; Source and Destination Port; Layer 4 Protocol (TCP/UDP/ICMP)'. Obviously this only applies to TCP/IP, and the reference to layer 4 only works by accident with the OSI model. What about ATM for example?
 * Layer 4 only works by accident ... right TCP/IP does not match into the OSI model. You know what I mean TCP/IP layer 4 as in transport layer.  ATM is a layer 3 network protocol.  It's cells can carry IP traffic.  And then flows can be observed in groups of packets.  What's the problem?  kgrr  talk 01:02, 27 March 2010 (UTC)
 * Obviously TCP/IP is the most important protocol stack, but it is not the only one. For example there was X.25. So any use of TCP/IP protocols should make it clear that they are only examples and the reader should not be expected to assume TCP/IP all the time. Hence I added 'TCP/IP' in the main text. However it seems to me that this description 'A TCP/IP flow can be uniquely identified by the following parameters within a certain time period: ...' actually contradicts RFC 3697? Specifically the bit 'However, a flow is not necessarily 1:1 mapped to a transport connection'


 * The main title is traffic flow. The article seems to assume this is the same as packet flow, but ATM cell flow, layer 2 frame flow, or even TCP segment flow could also count as traffic flow? So I think the article needs to be kept general. Aarghdvaark (talk) 12:10, 28 March 2010 (UTC)


 * And I'm not sure about your distinction between flows and routes. In a virtual circuit such as TCP, packets may go different routes but be considered one flow, OTOH in a pinned route environment such as with MPLS all packets (or frames) in one flow will go the same route. In fact your description above of a flow as 'groups of packets at one point in the network - at a router (e.g. Netflow)' does not work for TCP, as an odd packet in that flow may go a different route! Aarghdvaark (talk) 18:36, 26 March 2010 (UTC)


 * Again, flows have nothing to do with routes. Flows are packets with the same source address, source port, destination address and destination port, same TOS bits.  Do you somehow equate a flow to something that traceroute produces?  Like a list of IP addresses?  MAC addresses? And, Absolutely, the concept of flow works with TCP.  In the case of load sharing (where some packets go one way and other packets go another way), the observed flow at one router before the load balancer may see twice the flow as two routers down two different paths or routes through the network.  kgrr  talk 01:02, 27 March 2010 (UTC)


 * This is getting philosophical, as in 'you can never step in the same river twice'! Your idea of a flow seems to me to be specific in time and place, closely following RFC 3917, so that if we have a pinned route and no packet loss, etc., with packets going SRC - ROUTER A - ROUTER B - DEST, then I think you'd say the flow observed at ROUTER A is not the same flow as observed at ROUTER B. Whereas I'd follow RFC 3697 and say they were the same flow ('sequence of packets sent from a particular source to a particular ... destination that the source desires to label as a flow'). Hence although I would not say a list such as SRC, ROUTER A, ROUTER B, DEST defines a flow, I would say it defines the route (or more generally the path) of a flow? Aarghdvaark (talk) 12:10, 28 March 2010 (UTC)

Pocket traffic
What it is it 2401:4900:4BCC:FF9:1:0:78D2:9947 (talk) 17:00, 22 September 2022 (UTC)