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

From: Patrick Frejborg <[email-masked]>
Date: Mon, 1 Nov 2010 12:37:35 +0200

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.

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. 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.

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????

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
:-)

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.

Patrick

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 01 Nov 2010 10:29:46 -0400

I actually think that the question of where one should put end-point 
identification and where one should put path agility is somewhere more 
complicated than just assuming that we should put a session layer on top 
of transport.
While that approach works, it has drawbacks.
One example of the drawback is that the way MPTCP is architected, since 
it is using vanilla TCP, it can not switch which path it is using for a 
piece of data it has already sent unless that path is declared 
completely dead.  retransmission have to use the same path as the 
original (or else you stall that connection.

While I have opinions about how to do that, and there are some choices 
that seem to work well focusing on transport and above, the RRG is not 
the place to work out solutions for re-architecting the Internet 
Transport layer.  Among other things, there are quite a number of other 
experts who should be involved in that discussion, but have no interest 
in how routing works.

Yours,
Joel

---

From: Scott Brim <[email-masked]>
Date: Mon, 01 Nov 2010 12:14:21 -0400

> original (or else you stall that connection.

I don't want defend MPTCP, but actually that bit of data can be
retransmitted on another path.  Because of some middlebox behavior, it
will be retransmitted on the broken path as well until the problem is
resolved, but the endpoint can know to trash it.

As for recent messages in general, I get the feeling that we probably
need to revisit the concepts of "session" and "session layer", and maybe
what each layer provides in the way of end-to-end state.  Maybe in the
halls.

---

From: Patrick Frejborg <[email-masked]>
Date: Tue, 2 Nov 2010 09:12:34 +0200

On Mon, Nov 1, 2010 at 4:29 PM, Joel M. Halpern <[email-masked]> wrote:
> complicated than just assuming that we should put a session layer on top of
> transport.
> One example of the drawback is that the way MPTCP is architected, since it
> is using vanilla TCP, it can not switch which path it is using for a piece
> of data it has already sent unless that path is declared completely dead.
>  retransmission have to use the same path as the original (or else you stall
> that connection.
>
> While I have opinions about how to do that, and there are some choices that
> seem to work well focusing on transport and above, the RRG is not the place
> to work out solutions for re-architecting the Internet Transport layer.
>  Among other things, there are quite a number of other experts who should be
> involved in that discussion, but have no interest in how routing works.
>

I agree with you, this issue needs transport layer experts as well and
is out of scope for RRG.

If we look into the past, IPng was developed at the network layer with
the assumption that transport protocols remains intact. A product was
delivered and that has been available quite for a while on the shops'
shelves. Later on, the transport people came out with SCTP, assuming
that no changes are made on the network layer, also that product is
available on the shops' shelves. But either of these products has been
best sellers, right?

And here we go again - RRG is proposing some new network layer
solutions, assuming no changes are made to the transport protocol. At
the very same time, MPTCP is working on a new approach and assuming
that no changes are made to the network layer....nice products might
be delivered but will they ever become best sellers?

IMHO, the board should break this pattern, force transport&network
people work together on a product and see where it goes.

Patrick