[e2e] Port numbers in the network layer?
detlef.bosau at web.de
Thu Apr 25 15:17:05 PDT 2013
Am 25.04.2013 21:56, schrieb Hagen Paul Pfeifer:
> In theory, but in practice this do not work because not every link is Ethernet
> and you may end up re-parsing the packet to determine the transport protocol
> at each hop.
In German, I would say: "Jein". ;-) Unfortunately, not everyone on the
list understands German ;-)
So: Yes and no. On the one hand you point to an interesting issue: We
are a bit mixing up architectural considerations with implementation
So, we shouldn't discriminate IPv4 and IPv6 by Ethertypes because other
network technologies exist.
On the other hand: Do you know a current technology which is actually
being used that does not use Ethertypes?
Even Token Ring adopted Ethertypes, if indirectly using SNAP, years ago.
The more interesing observation is that TCP and IP "divorced" rather
late. And from my point of view, I'm interested in congestion control,
the very issue here is: Is congestion a phenomenon for transport
protocols? Or is congestion a network issue?
Actually, there are different positions here on this issue in
literature. This becomes quite obvious in the congavoid paper, where VJ
talks about TCP (or it's DecNET or OSI equivalents repsectively) and
keeps quiet about the existence of other protocols. While in the same
paper congestion is actually a network issue. When we investigate where
congestion occurs, congestion occurs in buffers. Particularly in those
which belong to the network layer. So we carefully fix a problem on the
network layer by means of the transport layer - and discuss "proper
layering" in this thread.
The major strategy in the congavoid paper is the "conservation
principle". And where the conservation principle may hold on a certain
network link - however, VJ obeys this principle by pursuing an
"equilibrium" there mere existence of which is highly questionable in
some cases, while he (not knowing it's existence at all) asks the
question how large a "sending window" may be - simply ignoring that the
sending window on transport layer is not necessarily the capacity of the
link (in the sense of the often mentioned "bandwidth delay product"....)
on the network layer.
We have a certain mess here.
BTW, in Keshav's thesis (I'm still to read some parts) congestion as
such is a network layer issue while on the transport layer, a flow
defines a congestion criterion. In my opinion it would have been better
not to talk about "congestion" here but to talk about "resource
scheduling" on the network layer here and to talk about "expectations to
the network by the application" on transport layer here. The very
interesting point here is, that we do routing on network layer.
And talk about path transparency from the transport layer's view point.
That's, in decent words, a bit unfortunate: Of course, I have absolutely
no interest to route packets belonging to the same stream along a path
which doesn't match my requirements! To determine a path without the
least consideration of the application's requirements is at least
questionable. (It's StarTrek networking: "To boldly go.....") (To our
non German friends: In Germany, it's about to be called "Throttlekom
Networking", with respect to one of our major ISPs in Germany, called
"Throttlekom". Formerly known as "German Telekom" which is about to
change it's traffic policies and SLA ... This is particularly important
for network simulation and underlines DPR's emphasis on user's
behaviour. German Telekom is about to change a user's access link's
properties depending on the user's download behaviour..., Refer to
So I see our next loss differentiation problem: I loss a consequence of
congestion, corruption or are "spurious timeouts" perhaps a consequence
of the German Throttlekom reconfiguring my Internet access link?
However, I think that the TCP/IP separation and the layering together
with VJCC raises some questions which perhaps leave room for some research.
More information about the end2end-interest