headers
Panos GEVROS | 1 Apr 2003 01:47
Picon
Picon
Favicon

Re: [e2e] Is a non-TCP solution dead?


----- Original Message -----
From: "Hari Balakrishnan" <hari <at> nms.lcs.mit.edu>
Sent: Monday, March 31, 2003 9:05 PM
Subject: Re: [e2e] Is a non-TCP solution dead?

> 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.

If I had to choose between
i)  optimise a L2 protocol for a particular transport and
ii) optimise a transport protocol in order to cope with different L2
protocols (not simultaneously)

I would almost instinctively choose option ii)  (probably becuase I have
convinced myself that if it is e2e it must be good :-)
without suggesting that L2 protocols should not be "well-designed" (whatever
this means)

suppose the wireless segment is at the edge of the path, one of the two
endpoints could be informed of the L2 technology and may negotiate with the
other endpoint the use of a particular "transmission control behaviour" -
provided that the transport offers several such options tailored for
specific environments, (the transport also offers the same api to the
application developer and can informed about the nature of the link it is
attached to)
(Continue reading)

Permalink | Reply | 79 comments |
headers
Mark Handley | 1 Apr 2003 02:10

Re: [e2e] Is a non-TCP solution dead?


>If I had to choose between
>i)  optimise a L2 protocol for a particular transport and
>ii) optimise a transport protocol in order to cope with different L2
>protocols (not simultaneously)
>
>I would almost instinctively choose option ii)  (probably becuase I have
>convinced myself that if it is e2e it must be good :-)
>without suggesting that L2 protocols should not be "well-designed" (whatever
>this means)

It's not that e2e must be good - it's an evolvability issue.

There are a vast number of end-systems out there.  To a first
approximation, they all speak more or less the same end-to-end
transport protocols, and this is necessary for interoperability.  For
this reason, plus the more recent proliferation of firewalls, NATs,
etc, it's likely that the number of end-to-end transport protocols
will remain small, with most of the service evolution happening above
the transport layer.  While transport protocol evolution does happen,
I'd bet money on the set of widely used transport protocols being
similar in ten years time.

There are many different link technologies out there.  Almost none of
them are the same link technologies that were around ten years ago.

Optimizing transport protocols for particular link technologies may
seem a good thing in the short term, but it harms the future.  It's
hard enough to get TCP right without link-layer dependencies in there.
And it's harder still if you have to optimize for arbitrary
(Continue reading)

Permalink | Reply | 77 comments |
headers
Injong Rhee | 1 Apr 2003 02:15
Picon
Favicon

RE: [e2e] Is a non-TCP solution dead?

Hans,

I don't think we are disagreeing here. I was just commenting on
link-level solutions; maybe I should refer it to be an application-layer
solution rather than e2e. Yes. Use of proxy might be necessary when the
servers are sitting outside the managed networks. No argument there. 

Injong

-----Original Message-----
From: end2end-interest-admin <at> postel.org
[mailto:end2end-interest-admin <at> postel.org] On Behalf Of Hans Kruse
Sent: Monday, March 31, 2003 5:31 PM
To: end2end-interest <at> postel.org
Subject: RE: [e2e] Is a non-TCP solution dead? 

Injong,

the problem here is the definition of "e2e".  Several others have 
summarized the PILC work better than I could -- the short answer is that

you either contain the application within the carriers network (as you 
imply below) _always_, or you allow at least some access to the Internet
in 
general.  The former is not really e2e unless you consider the 
carrier-internal network as the entire information universe for the
mobile 
users.

What you cannot do is let your non-TCP, or modified TCP, flows exit into
(Continue reading)

Permalink | Reply | 0 comments |
headers
David P. Reed | 1 Apr 2003 02:53
Picon

Re: [e2e] Is a non-TCP solution dead?

At 11:47 AM 3/31/2003 -0800, Mark Handley wrote:
>This raises a higher level issue: to what extent is a wireless link
>error a sign of congestion?

Relating this to my other mail:  in the RF medium, any number of 
communications can happen simultaneously.   Congestion of a sort (too many 
signals impinging on a single receiver antenna) results in a link error, 
but this depends significantly on the systems design of the receiver and 
its assumptions about the kinds of signals that may concurrently be 
transmitted.

There are many more dimensions of adaptation in the RF medium to adapt to 
variations in end-to-end bitrate demand.  These are extraordinarily 
interesting dimensions, far more so than mere rate control.  Simple 
examples include power control, rate adaptation, frequency adaptation, 
antenna steering, reconfiguration of network repeaters into new topologies, 
etc.   Many of these are not mere "link level" adaptations, but can involve 
the whole wireless network topology.

Given that the entire capacity of a wireless system varies tremendously 
depending on demand, one cannot layer wireless networks in the traditional 
way by assuming a set of independent fixed capacities at the physical level 
and then managing capacity above that layer as if the networks consist of 
fixed capacity links.

Thus Hari Balakrishnan's comment implying that partitioning wireless 
networks into a link layer and an end-to-end layer are misleading.   I 
personally suspect that end-to-end approaches are far more important for 
managing latency, throughput, etc. than he'd suggest.   But those 
end-to-end approaches will need to be worked out in a context that includes
(Continue reading)

Permalink | Reply | 1 comment |
headers
David P. Reed | 1 Apr 2003 02:31
Picon

RE: [e2e] Is a non-TCP solution dead?

At 03:51 PM 3/31/2003 -0500, Injong Rhee wrote:
>Is there enough commonality between wireless technologies to know what
>we are designing for?  And if so, what are the timescales we're
>talking about?

Wireless technologies that try to simulate wired technologies are the 
current case.

These will persist for some number of years, more than I would like, 
because the designers of such systems come from backgrounds that talk about 
stuff like "Links", etc.   I.e. they operate with a set of abstractions 
that blind them to alternatives.

My hypothesis is that there is a lot of commonality in such systems, 
because the designers are simulating a virtual device class with common 
characteristics, and that congestion will take the form of queue backups at 
these pretend "links" (which are about as real as the channels in a wired 
2B+D ISDN connection - i.e. fabricated by a multiplexing convention out of 
a single physical medium).

However, if you want to discuss the space of potential RF communications 
networks, you have to stop thinking about "links".   Start with the 
Slepian-Wolf theorem, and go on into multiuser information theory, add a 
dash of QED, throw in some control theory, and you might start to get some 
insight into what "congestion" might mean in the long term of wireless systems.

Wireless means there are "no wires".  Not even "virtual wires".
Permalink | Reply | 5 comments |
headers
Hari Balakrishnan | 1 Apr 2003 03:24
Picon

Re: [e2e] Is a non-TCP solution dead?


David,

I didn't say anything about how to run wireless (particularly multi-hop) 
networks at close to available capacity.  I do believe that integrated 
approaches are needed for that to work well.

My comments were restricted to dealing with wireless bit errors induced by 
corruption.  Period.  I don't think having TCP deal with such link errors is a 
useful optimization.

I do agree that TCP doesn't do a great job of estimating available capacity in 
many kinds of wireless networks, for some of the reasons you mention, and also 
because wireless capacity in many networks is tied to the details of the MAC 
protocol and we don't deal well with that kind of thing in TCP.  Also, I do 
think one can integrate wireless routing better with link characteristics.

My comments were not about general partitioning of functionality in wireless 
systems; they were about who should deal with bit corruption.  (I have been 
quite guilty of exploring end-to-end approaches to traditional lower-layer 
problems, including routing.)

Hari

> At 11:47 AM 3/31/2003 -0800, Mark Handley wrote:
> >This raises a higher level issue: to what extent is a wireless link
> >error a sign of congestion?
> 
> Relating this to my other mail:  in the RF medium, any number of 
> communications can happen simultaneously.   Congestion of a sort (too many
(Continue reading)

Permalink | Reply | 1 comment |
headers
David P. Reed | 1 Apr 2003 04:01
Picon

Re: [e2e] Is a non-TCP solution dead?

Hari - I wasn't attacking you - though I fear now that my remarks can be 
easily misinterpreted that way; sorry if they came out that way.  I'm 
familiar with your work, and I know you have explored these options.

What I meant to say is that your remarks may have been misleading (taken in 
the narrow context of this exchange).   Just as, it appears, my remarks may 
have been misleading. :-(

- David

At 08:24 PM 3/31/2003 -0500, Hari Balakrishnan wrote:

>David,
>
>I didn't say anything about how to run wireless (particularly multi-hop)
>networks at close to available capacity.  I do believe that integrated
>approaches are needed for that to work well.
>
>My comments were restricted to dealing with wireless bit errors induced by
>corruption.  Period.  I don't think having TCP deal with such link errors 
>is a
>useful optimization.
>
>I do agree that TCP doesn't do a great job of estimating available 
>capacity in
>many kinds of wireless networks, for some of the reasons you mention, and 
>also
>because wireless capacity in many networks is tied to the details of the MAC
>protocol and we don't deal well with that kind of thing in TCP.  Also, I do
>think one can integrate wireless routing better with link characteristics.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Saad Biaz | 1 Apr 2003 04:35
Picon

Re: [e2e] Is a non-TCP solution dead?

On Mon, 31 Mar 2003, Hari Balakrishnan wrote:

> My comments were restricted to dealing with wireless bit errors induced by
> corruption.  Period.  I don't think having TCP deal with such link errors is a
> useful optimization.

Hari,

If an ideal TCP yields ALWAYS an improvement of 20 to 150% in throughput,
would it be a useful optimization?

Saad.
Permalink | Reply | 0 comments |
headers
Cannara | 1 Apr 2003 04:49

Re: [e2e] Is a non-TCP solution dead?

Hans,

Your 2nd paragraph points up precisely a criticism of TCP -- it has become a
kludge ever since congestion management was added to prevent flows that
"...can damage the network as a whole, if these flows traverse the internet". 
The purpose of a transport is end-to-end, not to manage flow control for the
middle.

Alex

Hans Kruse wrote:
> 
> Well, there are really two different possible implementations here, and it
> is not clear which one you are talking about.
> 
> (1) If your mobile device is constrained to use "proxy" services run by the
> wireless provider to indirectly get information from the internet, you have
> a lot of non-TCP choices for getting data from the proxy to the mobile,
> since that flow is internal to the providers network.  Some folks will
> (probably correctly) claim that the mobile does not actually have "internet
> access" in this case, since it does not directly talk to internet servers,
> but it is a valid design.
> 
> (2) The minute the mobile sets up a clean end-to-end connection directly to
> arbitrary internet servers, you have to be much more careful.  The idea
> behind TCP is to prevent network overloads -- that is why TCP reacts with
> such caution; and on links prone to bit errors we know that to be a
> problem.  Bypassing TCP is not the answer, however;  by definition you are
> trying to create a system that is more aggressive than TCP, which we know
> can damage the network as a whole, if these flows traverse the internet.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Cannara | 1 Apr 2003 04:50

Re: [e2e] Is a non-TCP solution dead?

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
(Continue reading)

Permalink | Reply | 0 comments |

Gmane