[Iccrg] LT-TCP followup

[Michael Welzl]

Hi,

This is an interesting discussion.

I'd like to share my very personal, subjective view of the
IETF/IRTF related history regarding the congestion control
reaction with you:

1 in the research community, we had some proposals like
  TCP HACK, which simply suggested *not* to react to
  corruption at all

2 in the IETF, no corruption detection mechanism existed
  for a long time. After the long discussions preceding
  the specification of UDP-Lite, and the later addition
  of partial and separate checksums to DCCP, we now have
  the question of how to react to corruption when we see
  it on the table

3 during the DCCP discussions, Sally Floyd said that it's
  obviously not desirable to keep sending at a high rate
  in the presence of corruption. To me, this is intuitively
  clear: consider a source that sends at a high rate across
  a path which starts out with a wireless network but then
  includes lots of additional non-wireless hops. This source
  then contributes to congestion on these additional hops -
  or, in the absence of congestion, it increases the chance
  that congestion would occur

4 the group agreed that it can't decide on a correct
  behavior to corruption, thus left this issue open in
  the specification, pointing to future research

5 In Marina Del Rey (and a preceding email), Lachlan presented
  his theory which contradicts the intuition in item #3 above.
  Could it be that you *only* consider a wireless link, not
  the rest of the path? That could be a reason for your idea
  of actually increasing the rate to make sense in your setup,
  but not in practice

6 K K Ramakrishnan presented LT-TCP in Marina Del Rey too,
  and now there's this follow-up. Given the unknown *rate*
  response to corruption, in my very personal opinion,
  this seems to be the first acceptable proposal

Cheers,
Michael



On Thu, 2007-08-02 at 18:29 -0700, Lachlan Andrew wrote:
> Greetings all,
> 
> Vijay Subramanian's email reminded me to remind the group of my
> presentation to the ICCRG in February on what rate "should" be used
> when there are corruption losses.
> 
> An incomplete write-up is available at
> <http://netlab.caltech.edu/~lachlan/abstract/TCP_with_erasures.pdf>,
> but the main points are as follows:
> 
> If flows experience non-corruption loss, we still want to allocate
> rate "fairly".  In general multi-link networks, fairness cannot be
> measured by seeing how far rates are from equal, and is better
> measured using Kelly's utility maximisation framework.
> 
> The draft studies the (common) special case where the loss is on the
> last link, such as when downloading data from a wireless hot-spot.  If
> loss is high, we must distinguish between fairness of send rates and
> of receive rates.  We claim that fairness should be of receive rates,
> but that send rates should be used when calculating the level of
> congestion in the network.  In this framework:
> 
> - If we aim to get maximum throughput (ignoring fairness), the only
> flows which should transmit are those which have the minimum loss.
> - If we aim to get max-min fairness, the send rate should scale up as
> 1/(1-e)  where  e  is the erasure rate (that is, retransmissions don't
> count at all as part of our "fair rate")
> - If we want proportional fairness (as FAST implements) we should send
> at the *same* rate regardless of how much loss there is on the last
> hop.
> ******
> - If we want the same fairness that TCP-friendliness implies (which
> corresponds to "alpha=2" in Mo and Walrand's terminology and which I
> think is what LT-TCP wants) then we should actually send at a slightly
> *higher* rate (by a factor of 1/sqrt(1-e)) when there is loss than
> when there is no loss.
> ******
> 
> Agreement or disagreement would be welcome.
> 
> The above draft doesn't consider the implementation at all.  I'd
> encourage the LT-TCP designers to think about whether LT-TCP
> can/should be modified to use this "fair" rate, and I'd be happy to
> discuss it either on- or off-list.
> 
> Cheers,
> Lachlan
> 
> On 02/08/07, Vijay Subramanian <subrav at rpi.edu> wrote:
> >
> > At the end of the ICCRG meeting in Chicago , Wesley Eddy suggested that we
> > provide some input on how LT-TCP, our enhancements to TCP, can help in solving
> > some of the open research issues that are being currently addressed in the
> > ICCRG.
> >
> > Challenge 3.3: Corruption Loss
> > The draft poses the challenges: How should corruption be detected and what
> > should be the response?
> >
> > ... In particular, under no-loss conditions,
> > LT-TCP introduces no overhead and the behavior is identical to that of
> > TCP-SACK.
>