On Dec 19, 2014, at 4:24 PM, Matt <mattator@xxxxxxxxx> wrote:
> I believe wireshark may need to implement some data structures/GUIs
> helping with upcoming multipath protocols such as TRILL, SCTP, LISP,
> MPTCP...
This is not new.
For example, there's a certain protocol developed back in the mid 1980's in which "conversations" should arguably include several different transport-layer conversations - if you want to see the traffic between an NFS client and server, you would probably want to, at minimum, see NFS *and* mount *and* lock manager *and* status monitor *and* ACL protocol traffic (and perhaps some or all portmapper/rpcbind traffic).
So the Wireshark notion of "conversation" (a term I prefer to "connection", as not all conversations occur over a connection-oriented protocol, and "flow", as I think of flows as unidirectional and conversations are bidirectional or even multidirectional when they're not just *tete-a-tete*s) should probably be generalized - and extended both up to protocols running on top of transport protocols and down to link-layer and network-layer protocols.
