[e2e] Is a non-TCP solution dead?

[Injong Rhee]

Mark,

You raised an excellent point. Congestion in CDMA networks can happen
because of one of the three reasons (there could be more):

1. Wired line congestion
2. Air interface/link-level retransmission
3. Loss of channels because of contention among users in the same cell.

The first one can be in the range of RTT since TCP will reduce its
rates. The second and third ones can be as long as 100ms to a few 10s
seconds. Because of this, carriers tend to use large buffer (more than
10 to 20 seconds worth) -- typical bw and delay product does not work
here because delay can be much larger than just the best case
propagation delays (which is in the order of less than 1 second) -- I
hear other folks are commenting that this is overprovision of buffer.
Hell no! and it is an engineering choice by carriers for the network
environments where propagation delays are highly unpredictable and very
large.

Given that congestion lasts longer than RTT and delays get much larger
during the congestion of 2 and 3 (even for 1 because of large buffer), a
combination of loss and delays could be a good congestion indicator. 

Injong


-----Original Message-----
From: end2end-interest-admin at postel.org
[mailto:end2end-interest-admin at postel.org] On Behalf Of Mark Handley
Sent: Monday, March 31, 2003 2:48 PM
To: Spencer Dawkins
Cc: end2end-interest at postel.org
Subject: Re: [e2e] Is a non-TCP solution dead? 


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

This raises a higher level issue: to what extent is a wireless link
error a sign of congestion?  

Probably it isn't congestion in the sense of overflowing a router
queue.  However, if the link layer is well-designed, and attempts
limited retransmissions (or similar techniques), and the packet still
doesn't go through, then at that moment in time the link has zero
bandwidth.  Thus this is a form of congestion.

In a CDMA network, wireless channel congestion and link-capacity are
certainly coupled.  Thus again loss is related in part to congestion.

So perhaps it becomes an issue of timescales.  If link
congestion/corruption is coming and going on timescales a lot less
than an end-to-end RTT, then using *any* end-to-end congestion control
is going to be pretty inefficient (unless you get some really
predictable average conditions).  If link corruption is coming and
going on timescales of an RTT or greater, then theoretically an
end-to-end congestion control mechanism can in principle do OK.

In the later case, whether TCP does OK depends a lot on buffering and
queue management at the wireless hop.  Something like XCP with
explicit feedback and control should be able to do better, but I
definitely wouldn't rule out TCP being able to do acceptably will with
some minimal signalling.

In the former case, no end-to-end congestion control scheme is going
to be able to match the variation in available capacity.  


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?

 - Mark