In einer eMail vom 01.11.2010 11:37:36 Westeuropäische Normalzeit schreibt [email protected]:
On Sun, Oct 31, 2010 at 8:05 PM, <[email protected]> wrote: > In einer eMail vom 28.10.2010 07:59:24 Westeuropäische Normalzeit schreibt > [email protected]: > Hi Patrick, > I have a different opinion on what is the root cause. > We have a poor network layer. Due to some conex-email from Fred Baker I have > been remainded that the flow label exists for quite a while, but people have > no idea how to use it. Sad enough, but I think it's good, because it is so > easy to abuse it for weird concepts (like conex). This is just an example, I > could add many more. > > Lacking a session layer is a separate and additional issue. Right, the lack of session layer is not the only thing missing here but if you have a look on the RRG proposals I think every proposal is adding some kind of a session layer to the current architecture - thus I concluded that this is the root cause, the observation might be correct or wrong. But the RRG proposals differ how the session layer (LIS) is implemented into a routing architecture - we have the two main camps, CES and CEE. and my one-man-camp TARA :-) which is rather CES than CEE Another finding is the role of a multipath enabled transport protocol - SCTP and MPTCP provides a session layer but the current network architecture doesn't support very well the usage of multipath transport protocols. I am not an expert on MPTCP either. But I know for sure that MPTCP is the wrong way to go. What we need is a knowledgable network layer. For me MPTCP conforms with the DiffServ tradition: Develop some service based on not knowing what's going on in the network. MPTCP,Multihoming, Conex: All alternative routing decisions are based on "try and error". What is needed is a network layer which is able to prevent congestions as best as possible in the first place and, if the traffic is too intensive, knows how to resolve the congestion- rather than relocating it. But MPTCP,Multihoming, Conex decisions are absolutely done blindly. SCTP has been around for a while but is not much used, one issue is NAT but also to have several NICs at an endpoint is cumbersome. Imaging that every morning you arrive to the office you need to connect your laptop to several networks (physical or logical) in order to make use of SCTP - it would also make the routing and security architecture much more complex and expensive in the local network. Again, better routing is not task of SCTP. I had a look on one conex draft, it also assumes single path transport protocols and this is fair since the TCP/UDP are mainstreams protocols. What if multipath transport protocols would become mainstream instead: - the application layer is no longer accessing IP addresses, instead a session layer is shown towards the application (this is sort of inbuilt if the application really want to make use of the benefits of a multipath transport protocol) - for a session several paths (subflows) are established between two endpoints, if one subflow gets congested the transport layer multiplexes packets on the subflows where there is no congestion (think application layer is not that interested to know when there is a congestion in the network, the primary need is to get the packets sent over to the remote endpoint). - one interesting question is: if multipath transport protocols becomes mainstream how would that impact on the congestion behavior in large scale networks? Is the traffic engineering (dealing with congestion points) moved away from the network layer to the transport protocol layer/endpoints???? You see yourself: bad as can be. But it seems that the current addressing scheme needs to be changed so that the network layer could better support multipath transport protocols - if address scheme is changed then a sort of landmark routing architecture (your and mine thinking of hierarchical routing) can be designed and the multipath transport protocols can leverage the landmarks. And the outcome is close to the goals of compact routing :-) and even better, for sure. I know, a lot of changes at several layers - it is not only routing, also changes to the addressing scheme and transport layer is needed - and some applications will suffer....but hey, this is research, what development department decides to implement is a different story. Right. Heiner Patrick
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
