[e2e] Is a non-TCP solution dead?

[Cannara]

Agree 100% Hari.

Alex

Hari Balakrishnan wrote:
> 
> 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