[Iccrg] LT-TCP followup

[Lachlan Andrew]

Greetings KK,

Thanks for your detailed reply.  Now a long one from me...

Although the email below sounds argumentative, it isn't meant to be.
My calculations essentially justify LT-TCP's decision not to reduce
its rate in response to non-congestion loss.   We just differ in how
"TCP-like" we think this is.

On 04/08/07, RAMAKRISHNAN, K. K. <kkrama at research.att.com> wrote:
>
> -----Original Message-----
> From: Lachlan Andrew [mailto:lachlan.andrew at gmail.com]
> Sent: Friday, August 03, 2007 4:48 PM
> To: RAMAKRISHNAN, KADANGODE K (K. K.)
> Cc: Michael Welzl; iccrg at cs.ucl.ac.uk; David Hayes; Vijay Subramanian;
> Shivkumar Kalyanaraman
> Subject: Re: [Iccrg] LT-TCP followup
>
> My understanding is that you don't respond to lost packets.  That
> seems very far from following the "letter of the law" of TCP.
>
> KK> Let me clarify what we do. We respond to
> congestion, in the same way that TCP does and we depend on ECN for
> congestion indications. So, to that extent, we are following the "letter
> of the law" for TCP.

By "the letter of the law", I meant what RFC 2581 requires:
]   Therefore, when the first loss in a window of data is detected,
]   ssthresh MUST be set to no more than the value given by equation (3).
]   Second, until all lost segments in the window of data in question are
]   repaired, the number of segments transmitted in each RTT MUST be no
]   more than half the number of outstanding segments when the loss was
]   detected.

I don't think LT-TCP does this when a loss is detected, which is what
I meant when I said that it doesn't follow the *letter* of the law (as
I agree it shouldn't).

> So, if the intent and "law" of
> TCP is to respond to congestion, then we try to remain within those
> boundaries.

Yes, that is what I meant by the "spirit of the law".  I agree
entirely that you keep within the spirit of the law.


So far I think that we agree that LT-TCP does the window-manipulations
that were the "intent" of TCP, rather than following the "MUST"s of
RFC 2581 (or SACK, or ...).  I think the disagreement is whether the
intent was for TCP to specify window manipulations or to specify how
fast a data-stream can be sent.  Is that correct?


> KK> We agree with you that ultimately application performance should be
> the main criterion. But from a resource perspective each individual
> entity (e.g., flow) that qualifies to be treated distinctly, may be
> viewed as getting an equal share (e.g., when max-min is the criterion
> for fairness).

> Then, the total load (data, headers, other "stuff" like
> FEC) all get bundled into the share that the entity is eligible for.
> There are multiple fairness goals, and that is why we have discussions
> about what is the right thing to do.

Exactly.  I'm just not quite sure what fairness goal LT-TCP has (or
most other new TCP algorithms).  Since this is the IRTF, not the IETF,
I think we can take a more progressive position and state what
fairness we are trying to achieve, and then tailor the algorithms to
achieve it, rather than trying to make the smallest possible changes
to existing (unfair) algorithms.  Do you agree?

To me, fairness goals are expressed in terms of the "response
function" (uniquely determined by Kelly's "utility" function).  What I
did was take the utility function for TCP's *existing* response
function (1/sqrt(p)) and optimise that given loss in the network.

Note also that TCP doesn't give max-min fairness.  If its aim were to
give max-min fairness to the TCP streams, then streams with lower
throughput would be given *more* preferential treatment than I'm
advocating, not less...

> If SACK has a small enough RTT, then even at high loss
> rates it will get almost full link utilisation.  What does LT-TCP do
> then?
>
> KK> We do not measure the capacity that a competing TCP-SACK flow does
> not use. If the channel is idled because TCP-SACK suffers a timeout, it
> is only then that LT-TCP would be able to utilize that bandwidth. In the
> case that there is a small enough RTT and SACK is good enough even under
> the high loss rate to NOT experience a timeout, then TCP-SACK and LT-TCP
> would use that link fairly.

Are you saying that LT-TCP will have the same window as SACK if there
are corruption losses?  I thought that LT-TCP didn't reduce its window
based on missing packets, but SACK does.  Sorry that I don't remember
the details of the experiments you reported in Feb -- are they on
line?

Alternatively, are you saying that LT-TCP has a larger window, but for
some other reason it still limits its rate to be equal to SACK?

Note that I'm not saying LT-TCP *should* be constrained to have
exactly the same rate as SACK, even when SACK can fully utilise the
bandwidth.  Some unfairness during the transition to a better (fair)
set of protocols is fine by me.

>> We would like to emphasize that LT-TCP's
>> advantage is only that it may use the residual capacity that is left
>> un-utilized by TCP-SACK in such environments.
>
> My understanding is that a flow which sends fast enough to induce
> congestion losses will always slow down a competing flow which
> responds to losses.
>
> KK> If a flow induces congestion - period - and responds to ECN, then it
> will not slow down a competing flow that also responds to congestion
> indication. The issue, which you raise is: what happens when loss is the
> primary source of congestion indication. This is where we need to
> separate the two: congestion indication, and lossy channels. We used ECN
> to disambiguate them.

Consider a link such that two flows with loss probabilities  p=0.02
would saturate the link.
If we have 1% packet losses and 1% ECN marks, SACK will respond to a
loss rate of 2%, while LT-TCP will respond to a loss rate of 1%, and
hence send faster even though two SACK flows could saturate the link.
If LT-TCP slowed down toward half the link capacity, then the
congestion would reduce.  Then (loss+ECN) would drop, and so SACK
would increase to pick up the slack.

(Again, I'm not saying this is bad; just that it contradicts the
statement that LT-TCP only takes bandwidth SACK could not utilise.)

> KK> The main issue is
> whether we are changing the mechanism, and what is "the mechanism"? If
> loss as being the sole indication of congestion is the dominant part of
> "the mechanism", yes we are diverging from that.

Yes, to me treating loss as a sign of congestion is fundamental to the
mechanism of TCP.  All other decisions seem to stem from that
limitation.  There are (and were in '88) many better ways to control
rate if we're not limited to measuring rare events like packet loss.

Although I also don't like using loss as the primary congestion
measure, it does have the distinct advantage that it also reponds to
layer 2 congestion, which explicit-signalling (like ECN) doesn't.

> And honestly, we have tried to retain
> backward compatibility, not just appear to be backwards compatible.

Yes, I didn't mean to seem to accuse you of "window dressing".  It
comes down to the difference between backward-*compatible* algorithms
vs *similar* algorithms.

My point was just that ignoring loss is intrinsically a   much
bigger departure from standard TCP than simply allocating rate to the
payload rather than the payload+header (as is done when any TCP flow
is tunnelled).  Emphasising the similarity on the level of
window-manipulations is probably sensible for getting LT-TCP
standardised, but taking the approach of choosing desired flow-level
properties (like rate allocation) and then designing
backward-*compatible* algorithms  to implement them seems to me a
better way to develop the internet.  The latter is the approach that
TFRC has taken.

The reason that LT-TCP is good is because because of the flow-level
properties it has, not because the equations are similar to TCP.  My
calculations can be used to show the "optimality" (by some measure) of
LT-TCP's flow-level properties, or to tweak it to make it "more
optimal" (by using TCP-like measures throughout, instead of mixing
TCP-friendliness with Proportional Fairness).

Cheers,
Lachlan

P.S.
Speaking of tunnels, perhaps LT-TCP's mechanisms could be implemented
like IPsec, as a tunnel.  If we tunnel SACK in a new FEC-enabled IPfec
(or IP-LT), then we're allocating TCP's full "fair" rate to the
payload...  (This isn't a serious suggestion -- it's much more
aggressive than what I was proposing.  I'm just saying that
payload-rate allocation is not unheard-of in the IETF.)

-- 
Lachlan Andrew  Dept of Computer Science, Caltech
1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
Phone: +1 (626) 395-8820    Fax: +1 (626) 568-3603