[e2e] Is a non-TCP solution dead?

[Mark Handley]

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