[e2e] Is a non-TCP solution dead?

[Spencer Dawkins]

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