[Tsvwg] Re: [e2e] e2e principle..where??....

[afalk at PanAmSat.com]

> so with this description a satellite system that uses 2 proxies
> on each end of a satellite link and does its own protocol between 
> the proxies is also compatible with the e2e argument.
> server---proxy1---proxy2---client
> so long as the bits comming out on the proxy1---server and 
> proxy2--client are the same...?
> the only gurantee is that as you say.."the bits get delivered 
> as sent......and the bits are unmodified..." 
> so inbetween the 2 proxies compression etc...are all completely valid?

Manish-

I think a lot depends on what the proxies are doing. Many proxies in this
configuration terminate the TCP connections from one or both endpoints (see
PEP) and don't maintain that the "the bits get delivered as sent" -- this
mandate includes the packet header bits (i.e., the semantics). However, if
the 'proxies' are performing compression or forward error correction -- bit
transparent operations, the end-to-end argument is maintained (see SLOW,
ERROR). 

Since people are usually motivated to do this to improve performance or link
utilization, it's worth noting that interactions between the what the
proxies are doing on the link can have unpleasant and surprising effects on
the end to end performance or goodput (see LINK and, particularly, ARQ) of
the traffic passing through the links affected. This doesn't mean that it's
always a bad idea to use such mechanisms, only that they must be applied
with care.

I guess there are two aspects to the end-to-end argument: It's a design
principal to use when chosing how to architect a piece of network
technology. In a nutshell, 'keep the network as dumb as is reasonable.'
('Reasonable' being somewhat subjective.) Putting increased intelligence in
the network increases the risk of scalability and reliability problems
(witness ATM). However, we often use it as a shorthand for one of the very
useful results of a dumb network: transparency. Technologies that violate
the end-to-end principle often obscure network transparency. From an
architectural perspective, this seems like a much more dangerous but less
quantifiable risk. Network transparency is an enabler of past and
(hopefully) future innovation built which exploits the flexibility of the
network.

--aaron

PILC WG drafts have much to say on the subject of proxies and performance:

PEP: http://www.ietf.org/internet-drafts/draft-ietf-pilc-pep-07.txt
SLOW: http://www.ietf.org/internet-drafts/draft-ietf-pilc-slow-06.txt
ERROR: http://www.ietf.org/internet-drafts/draft-ietf-pilc-error-07.txt
LINK: http://www.ietf.org/internet-drafts/draft-ietf-pilc-link-design-05.txt
ARQ:
http://www.ietf.org/internet-drafts/draft-ietf-pilc-link-arq-issues-01.txt