Subject: Re: [rrg] Last call: Design goals

From: [email-masked]
Date: Mon, 1 Nov 2010 14:58:50 EDT

In einer eMail vom 01.11.2010 11:37:36 Westeuropäische Normalzeit schreibt  
[email-masked]:

On Sun,  Oct 31, 2010 at 8:05 PM,  <[email-masked]> wrote:
> In  einer eMail vom 28.10.2010 07:59:24 Westeuropäische Normalzeit  
schreibt
> [email-masked]:
> 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

---

From: Scott Brim <[email-masked]>
Date: Mon, 01 Nov 2010 15:05:00 -0400

On 11/01/2010 14:58 EDT, [email-masked] wrote:
> I am not an expert on MPTCP either. But I know for sure that MPTCP is
> the wrong way to go.

If you want to contribute to the discussion of the usefulness of MPTCP,
please contribute to the multipathtcp mailing list.