[e2e] Is a non-TCP solution dead?
Injong Rhee
rhee at eos.ncsu.edu
Mon Mar 31 13:00:46 PST 2003
But in the absence of deployed solutions for link-layer or MAC protocol
(it takes time carriers to update them after they put it so much money
into the current infra), link-level solutions are really out of reach
for application developers.
Another point I want to make is that the servers are typically located
within carrier's managed networks. In this case, the wired line problems
are less likely and most of problems we experience are wireless line
problems. In the case, some e2e can be a good alternative.
Injong
-----Original Message-----
From: end2end-interest-admin at postel.org
[mailto:end2end-interest-admin at postel.org] On Behalf Of Hari
Balakrishnan
Sent: Monday, March 31, 2003 3:05 PM
To: Spencer Dawkins
Cc: end2end-interest at postel.org
Subject: Re: [e2e] Is a non-TCP solution dead?
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
>
More information about the end2end-interest
mailing list