[e2e] Is a non-TCP solution dead?

[Saverio Mascolo]

Hi,

 I would say that both e2e optimization and link layer optimization are
equally necessary and important.

Examples:

-Link layer mechanism such as ARQ+FEC are necessary to provide a reliable
wireless link. This is an evident requirement that goes beyond the fact that
TCP does not work well over unreliable links

-e2e optimizations are also important because they improve TCP over
"everything". F.i. the e2e bandwidth estimation introduced by Westwood+ TCP
improves: (1) throughput over unreliable links (some "quote" of
unreliability can survive to link layer recovery mechanism in some cases);
(2) fairness over wired links etc.

Moreover, as  Injong says, e2e or application level solution are important
"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."

Finally I have a question for Mark Handley. I think that XCP has important
stability problem. In fact XCP has a margin stability that is very small and
must be kept positive by using very low-gain controller, that implies low
performance. On the other hand, you should notice that  TCP flow control
already provides explicit feedback, which is the Advertised Window. The
Advertised Window is used in a simple proportional controller by TCP and
this controller is much more stable that a proportional + integral
controller that is the one used by XCP (we have the paper "Generalized
window advertising for TCP congestion control", European Transactions on
Telecommunications, Dec. 2002 showing how the current  TCP congestion
control can be easily generalized to provide explicit feedback).

Saverio Mascolo

----- Original Message -----
From: "Hari Balakrishnan" <hari at nms.lcs.mit.edu>
To: "Spencer Dawkins" <spencer_dawkins at yahoo.com>
Cc: <end2end-interest at postel.org>
Sent: Monday, March 31, 2003 10:05 PM
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
> >
>
>