[Iccrg] LT-TCP followup
michael.welzl at uibk.ac.at
Fri Aug 3 07:28:15 BST 2007
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
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
> 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
> - 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.
> 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.
More information about the Iccrg