[e2e] Multiple TCP-friendly Sessions and Cong. Control in user-mode?
touch at ISI.EDU
Fri Apr 12 15:31:41 PDT 2002
David P. Reed wrote:
> At 01:21 PM 4/12/2002 -0700, Joe Touch wrote:
> My position is that the paper communicates only one point directly
> (which has been called 'weak' in other places):
>> an E2E service cannot be created exclusively by the
>> composition of HBH services
>> There may have been other agendas at work when writing the document,
>> but this is the only one that I feel is established to readers of the
>> document. I don't feel that the document sufficiently asserts that
>> there are reasons for preferring E2E over HBH, only that HBH cannot be
>> composed to create E2E.
> I don't think we miscommunicated our point, nor were there hidden
> agendas we didn't state. Here's a direct quote from the opening of our
> paper, which defines what an end-to-end argument is:
> In a system that includes communications, one usually draws a
> modular boundary around the communication subsystem and defines a
> firm interface between it and the rest of the system. When doing so,
> it becomes apparent that there is a list of functions each of which
> might be implemented in any of several ways: by the communication
> subsystem, by its client, as a joint venture, or perhaps
> redundantly, each doing its own version. In reasoning about this
> choice, the requirements of the application provide the basis for a
> class of arguments, which go as follows:
> The function in question can completely and correctly be implemented
> only with the knowledge and help of the application standing at the
> end points of the communication system. Therefore, providing that
> questioned function as a feature of the communication system itself
> is not possible. (Sometimes an incomplete version of the function
> provided by the communication system may be useful as a performance
> We call this line of reasoning against low-level function
> implementation the "end-to-end argument."
> Some observations, compared with your point above:
> - we never said Hop-by-Hop, because the argument applies even if the
> communications system has no "graph structure".
Agreed - there are two ways to do non-E2E:
1) HBH (staging at intermediate points, whether inside the net
or even talking to multiple endpoints in succession may qualify)
2) from a non-endpoint
this is harder to define; the only definition of endpoint I
have been able to determine is "that which _I_ can kick" (or
that which _I_ care about). everything else is 'middle'.
which means an endpoint might be an application, a host,
a router, a link interface, or just about anything, depending
on who is talking :-)
> - we never said this applied only to the functions contained in the
> "transport layer".
Agreed - nor do I, FWIW. Though talking about E2E about a link is a
little odd, but certainly a good example of #2 above.
> - the inability to compose HBH solutions to form an E2E solution is only
> one way in which one satisfies the predicate of an end-to-end argument
> (i.e. that one cannot implement the function completely within the
> communications system). A more fundamental reason would be that the
> communications system doesn't have and can't have enough information to
> perform the function correctly... and that has nothing to do with
> hop-by-hop composition.
I'd say one follows from the other, i.e., it is the lack of sufficient
information which prevents composition.
More information about the end2end-interest