[e2e] Is a non-TCP solution dead?

[Hari Balakrishnan]

TCP over wireless has been an area of active work for a while.  It seems to be 
generally true that good local recovery solutions perform pretty well and I 
haven't seen any end-to-end solution that performs as well as good local 
optimizations.

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.

Hari

> Hi, Alex,
> 
> There are a couple of interesting points here:
> 
> - For a few minutes during the early days of the PILC working
> group, we were excited to think that we might be able to treat
> ECN as an unambiguous indicator of congestion, so when we were
> using ECN (even "fully-deployed" ECN), we could interpret loss
> in the absence of ECN Congestion Encountered as an indication of
> transmission error, and not congestion.
> 
> Of course, we couldn't do this, because at a sufficiently high
> congestion level, we lose packets marked with CE, so we would be
> retransmitting at exactly the wrong time.
> 
> One of the reasons we were "dragging our feet" on error
> notification in PILC was because we couldn't come up with a
> reliable way to tell a sender about transmission errors that
> allowed the sender to know that there was no possibility of
> simultaneous loss due to congestion, so no possibility of making
> congestion worse for a sustained period of time.
> 
> - If we use something besides TCP over wireless links, we have
> two choices, (a) use a Performance Enhancing Proxy to translate
> TCP over wireline into something else when you hit
> wireline-to-wireless borders, or (b) use "something besides TCP"
> end-to-end.
> 
> Since one of the big issues with TCP has been slow start, it's
> difficult to see how (a) works without spoofing ACKs to a
> wireline TCP sender. Without ACK spoofing, the sending TCP
> executes slow start and congestion avoidance at end-to-end round
> trip latencies. I do believe some applications could handle
> this, but it's enough of a change in the "transport contract"
> that I don't see how we can just start doing it and hope that
> application protocols are doing their own end-to-end ACKs at the
> application layer.
> 
> If the wireless community continues to move toward "walled
> garden" deployments, so a single carrier can control its
> wireline servers and wireless clients, (b) could happen. But
> this would require a change from the late 1990s, when the goal
> was to allow wireless users to use arbitrary wireline services -
> there were some servers deployed that ran WAP 1.X end-to-end,
> but this deployment just didn't go as far as the industry had
> hoped.
> 
> Maybe we are closer today, with more realistic expectations and
> wider availability of downloaded applet technologies, and I know
> of proprietary implementations that run over UDP from mobile
> devices to a server, both of which are provided by the same
> vendor, so that a carrier really can deploy servers and clients
> in a more straightforward way.
> 
> But it's important to realize that we need something beside less
> foot-dragging in the IETF to solve this problem.
> 
> Spencer Dawkins
> 
> --- Cannara <cannara at attglobal.net> wrote:
> > Injong, excellent points.  There is no reason to continue to
> > believe that TCP
> > has any long-term purpose, especially in the radio-link
> > environment.  Foot
> > dragging in the IETF on ridding TCP of its '80s myopic flow
> > control has left
> > us with a poor transport for errored links.  It will be great
> > if the control
> > radio-link providers have can generate a better thought-out
> > transport, even if
> > it simply rides on IP or UDP.  We are in hope.
> > 
> > Alex
>