[e2e] Port numbers in the network layer?

[Detlef Bosau]

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 
issues here.
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?

I don't.

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
http://www.spiegel.de/international/business/government-wary-of-telekom-limits-on-flat-rate-dsl-access-a-896435.html
for details)

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.