[e2e] Is a non-TCP solution dead?

[Cannara]

Panos, I suggest that you left out III -- "I & II are not relevant to end-end
transports.  All transports deserve the same quality datagram service from L3
and L2."  Why is TCP to be babied, but not UDP, or plain IP Continuation?  The
L3+ end points need have no knowledge of the links, nodes, proxies, whatever,
on a path.  The Internet, in fact, was designed without benefit of the
concepts of Layers 1 & 2.  All that was assumed was a "gateway" (poor name)
for routing packets via IP addresses.

Alex

Panos GEVROS wrote:
> 
> ----- Original Message -----
> From: "Hari Balakrishnan" <hari at nms.lcs.mit.edu>
> Sent: Monday, March 31, 2003 9:05 PM
> Subject: Re: [e2e] Is a non-TCP solution dead?
> 
> > Even if there were reasonable end-to-end solutions, from an architectural
> > standpoint it seems to me to be a mistake to try and deal with wireless
> > vagaries as an end-to-end problem.  In my opinion, well-designed
> link-layer and
> > MAC protocols are the way to go.
> 
> If I had to choose between
> i)  optimise a L2 protocol for a particular transport and
> ii) optimise a transport protocol in order to cope with different L2
> protocols (not simultaneously)
> 
> I would almost instinctively choose option ii)  (probably becuase I have
> convinced myself that if it is e2e it must be good :-)
> without suggesting that L2 protocols should not be "well-designed" (whatever
> this means)
> 
> suppose the wireless segment is at the edge of the path, one of the two
> endpoints could be informed of the L2 technology and may negotiate with the
> other endpoint the use of a particular "transmission control behaviour" -
> provided that the transport offers several such options tailored for
> specific environments, (the transport also offers the same api to the
> application developer and can informed about the nature of the link it is
> attached to)
> 
> the negotiation may succeed or fail based on policy and/or compatiblity
> criteria;  the"server" may grant or reject the request and in certain
> envirnonments I wouldnt worry too much about being tcp-friendly
> 
> imho this looks like a cleaner solution
> 
> Panos