Subject: RE: Updates for ERROR after WG last call

From: "Jan Kullander (ERV)" <[email-masked]>
Date: Thu, 14 Sep 2000 17:33:52 +0200

> -----Original Message----- From:	Lloyd Wood [SMTP:[email-masked]]
>
>On Wed, 13 Sep 2000, Jan Kullander (ERV) wrote:
>
>> It is an unfortunate property of TCP congestion control that a 
>> connection generally benefits more from larger MTUs even if it 
>> means that more correctly received data is needlessly retransmitted.
>> In other words, the performance of a single TCP connection may 
>> benefit from a large MTU size regardless of fragmentation.
>
>so you design a link to advertise a large MTU size, and to do implicit
>fragmentation and reassembly of submultiples of that size below the IP
>layer itself. (Hence >9000 bytes for SMDS, ATM, etc. - RFC1626. Worth 
>sticking a pointer to this in somewhere.)
> 
>
>> (This can be perceived from the ADVICE draft formula:
>> 
>>           MSS    1
>> BW = 0.93 --- -------
>>           RTT sqrt(p)
>
>which doesn't look anything like e.g. equation 3.4 of [OKM96], not
>least because TCP throughput or usage is *not* bandwidth. I'd expect
>link designers to understand bandwidth to mean *their* link
>bandwidth (as Jan illustrates below), so this worries me.

Do I? My English must be stinking.
>
>(Everywhere I look on
> http://www.psc.edu/networking/tcp_friendly.html
> I find different values for the constant; I'd just put k there and
> indicate a range for k, to emphasise that the models are rules of
> thumb rather than something that can be used rigidly or
> axiomatically. This isn't a trig formula; it depends on a large
> number of assumptions about behaviour subject to change, not on
> unchanging axioms.)
>
>
>> where p is the packet loss rate. 
>
>I'd just like to point our here that packet != segment != unit of
>bandwidth. Dimensional analysis shows the formula's a rule of thumb.
>
>
>> If we assume that 
>> 
>> p = MSS * BER (of the ERROR link)
>> 
>> we see that BW is proportional to sqrt(MSS).
>
>and what do you (and the draft) mean by BW?
>
>
>> All this is of  course simplifications but it hold true for
>> reasonable values.)
>
>oversimplifications, I suspect.
>
>
>> So what conclusions are there? One is to advice link layer designers
>> to consider the ADVICE formula 
>
>which might be why it's in the advice draft. I'm not convinced that's
>_that_ good an idea, though. A lot depends on what the link-level
>designers use the formula _for_.
>
>
>> and not only optimise link layer 
>> transmission without knowing the implications on TCP.
>
>that much is good advice in general; very much the thrust of pilc.
>
>
>> Another is to
>> point out that it pays to make the link reliable (according to the 
>> formula a doubled RTT is balanced by reduction on packet loss to 25%
>> which should not be difficult to do better than).
>
>That's making some assumptions about the applicability of and
>invariance of the formula. Note that BW in the formula is *not* the
>(fixed) link bandwidth, but TCP's use of it: its overall throughput
>(as opposed to goodput).

I make no assumptions of the applicability of the formula, I just point out
that a reduction to a quarter of the packet loss is worth a doubled RTT
according to the formula.

If you do accept the formula as rule of thumb you may see this as a
distinct indication that it is likely that even a modest improvement of link 
reliability is worth quite some delay (from TCP connection point of view).
>
>Phrases like 'the bandwidth of a TCP connection' (in
>http://www.psc.edu/networking/papers/tcp_friendly.html) just confuse
>the issue. Lousy non-engineering jargon, if you ask me.
>
>Since throughput's not an invariant and depends on the other values,
>and the formula is merely giving an indication of TCP's use of
>available unlimited end-to-end capacity, I believe your use of the
>formula in that way is... well, unwarranted. You're jumping from an
>equation describing a _path_ to detailed _link_ design. If your
>argument was correct, then implementing a reliable service *under* TCP
>end-to-end would suddenly seem to be be a Good Thing. Which it isn't.

No, it would not be a good idea to implement an e2e reliable service under
TCP since it would either nullify the congestion control in TCP or reinvent 
it (and then we wouldn't gain anything).

To implement a reliable service over a link on the other hand might be 
beneficial for TCP, especially if that service didn't have to implement any
congestion control (since it knew available link capacity anyway). (It 
would of course have to drop packets exceeding link capacity if you call 
that congestion control).
>
>(and the URL in [OKM96] in the advice draft and linked to from the
>TCP friendly website is no more. There's a copy at:
>http://citeseer.nj.nec.com/ott-stationary.html )
>
>A doubled RTT suggests that you're considering some form of link ARQ
>(and that you're thinking about endhosts at each end of the link,
>rather than longer paths just using the link), and that the link time
>is tiny compared to the RTOs of the TCP connections using the link.

You are making a lot of assumptions, why? To make a conversation?
>
>Fine for a mobile cellular hop, not so good for geostationary
>satellite. You could get a reliable-enough-for-TCP link by just using
>better error control coding etc...

It might indeed make sense even to implement a reliable service over a
satellite if that service knew the available link bandwidth! Then a lost 
packet could be retransmitted without the multiplicative decrease. Now I 
do not claim that this would be to prefer to "better error control etc..." and 
I dot even claim that it would be a good idea under all circumstances.
It would e.g. be difficult foresee the penalty of the prolonged RTO if 
other parts of the TCP path were lossy or congested. Still, the formula 
suggests that the penalty might be worth while... (And if spurious 
retransmissions would prove to be a problem (which I doubt) a semi-
reliable link service with limited ARQ would probably still be worth while).
>
>the more I look at the formulae glibly quoted in the advice draft, the
>more I think those sections need some tweaking and an even stronger
>caveat detailing the differences between link and path. These formulae
>_will_ be misused if we're not careful.
>
>BW isn't even explicitly defined, which has to be an oversight.
>
>cheers,
>
>L.
>
><[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

Regards
Jan Kullander

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 14 Sep 2000 18:21:44 +0100 (BST)

On Thu, 14 Sep 2000, Jan Kullander (ERV) wrote:

> I make no assumptions of the applicability of the formula, 

You're assuming that the formula is applicable in that way.

> I just point out

You do not control packet loss of the entire TCP path.
You do not control RTT of the entire TCP path.
TCP throughput depends on the entire path.

The formula does not reflect slowstart well, either; it simply gives
an upper bound on performance.

> it (and then we wouldn't gain anything).

but you're effectively using the formula to advocate just that, since
with an e2e reliable service under TCP, then TCP would see a longer
RTT but less packet loss, allowing TCP's throughput to remain the
same. (Which, in reality, it won't.) This is something of an
indication that the formula may not actually be applicable, yes?

> Still, the formula suggests that the penalty might be worth
> while... 

an approximation is no substitute for reality. remember, you're
assuming that the TCP throughput is at its upper bound in order to
make the packet loss/RTT tradeoff feasible, whereas it's far more
likely to be somewhere else in the continuum.

(We need another formula that says how often TCP within 5% of its
predicted upper bound, to give us a degree of confidence in the bound 
formula...)

L.