[e2e] Is a non-TCP solution dead?

[Jon Crowcroft]

so the problem with CDMA is that inference and noise are
indistingiushable - esp. for wideband - basically, there is NO option
like ECN capable MAC (to take the media as the router as you imply)

you need a +distributed+ mac solution (see our wiopt paper, or others
e.g. one in infocom this week i seem to remember seeing on the program)

the point about wireless is that yo ushare the channel with legitimate
other users like the entire universe of RF special effects out there
as well as normal human centric sourced traffic...

with non CDMA, the problem may be easier tho (obviously with FDM or
even OFDM, there are ways to tell if its interference

actually even with cdma there are a few possible power tricks, but
most the really really clever modulation and dynamic distrib.
power management stuff being developed will defeat even that...
at least as far as i understand it, which aint a lot of course:0)

In missive <90036.1049140066 at aardvark.icir.org>, Mark Handley typed:

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

 cheers

   jon