[e2e] j'accuse NFV

[Detlef Bosau]

Am 05.05.2015 um 12:29 schrieb Djamel Sadok:
> nothing is wrong with e2e encryption. Perhaps all traffic will be encrypted
> in a few years anyway.
>
> I only want to find out if there could be a way to adopt NFV while leaving
> a choice for traffic that does not want to be NFV´ed perhaps because of the
> fear that some middlebox function (NFV) may alter some e2e
> http2/QUIC/SPDY/.. clever adaptation that booble engineers have  just come
> up with.
>
> Djamel
>
There is a quite helpful paper, which you may want to reed:

http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf

Unfortunately, we often talk about some "end to end principle", which
doesn't exist and which the mentioned paper did not want to establish.
To me, it is a framework, some very thought out advice how rationales
can be found to answer the questions
- where network functions should be placed and
- why.

So if we have, e.g., some kind of transport protocol, which provides for
an ordered, reliable byte stream, the virtual channel between the end poins
IS strictly virtual.

A packet, once it is sent to the channel by the senmder "disappears" in
the channel and "appears again" not before the receiver.
So, to my understanding, and I'm a bit nasty here because this way of
thinking is not necessarily shared by all readers here, a very basic
problem of middle boxes is
- where to place them and
- how to alter a flow in some determined manner!

This is like placing a door on a soccer field: When a ball is shot, he
left the player's foot and it is in the game gain, when it is received
by another player.
In a packet switching network, anything what happens between entering
and leaving the path should be completely transparent.

So the question is once again: Where should we place middleboxes?

During the last weeks, I've seen some discussion about Baran's work on
the history list.

So let me say, why I think my thought is nasty: Think about TCP and path
changes. Some people even think about a "multipath TCP".

When I consider Baran's work, Baran had a strong emphasis on path
redundancy.  So, with respect to a certain packet, we agree upon a
sender and a receiver. But do we agree upon anything more?

The more I think about it, the more I tend to give the answer: No, we
don't.

And the very strength of the e2e way of thinking is THAT WE DON'T.

E.g., when a packet misses its receiver because some node or link along
the path fails, the sender may retransmit a packet - and the packet may
take a different route from the sender to the receiver.

So, where shall middle boxes be placed?

That doesn't mean, they were no rules for packet forwarding, of course
they are.

But it does mean, that a "path" between sender and receiver may be not
completely visible from "within" the network but something, which may be
visible from "outside" the network.

>From a view "within a network", there even might be no awareness, that a
certain path even exists.

>From a view "outside the network", the path exists and may work pretty
fine.

It is difficult to think that way.

But the more I think about it, the more I think, I'm in my own way, when
I think about networks.

And particularly with respect to Baran's work and the basic idea of
robustness by path redundancy, I try to leave the idea of "concrete
paths" - and hence focussing on middle boxes or concrete functions
placed on certain places along a path.

Perhaps, I want to define some requirements for packet forwarding from
the outside. (A classical example is a packet's TTL)

But mainly, from an outside perspective, I'm interested that a network
DOES the forwarding job. And not in HOW it is done.

E.g., I see some author's who want to drop greedy routing.
Why?
A possible (and very convincing!) argument is: For the purpose of load
sharing!

And latest in this context, talking about middle boxes and the like
doesn't really make sense.