Subject: RE: Updates for ERROR after WG last call

From: "Jan Kullander (ERV)" <[email-masked]>
Date: Wed, 13 Sep 2000 13:00:57 +0200

>-----Original Message-----
>From:	Dawkins, Spencer [SMTP:[email-masked]]
>Sent:	Tuesday, September 12, 2000 8:45 PM
>To:	'PILC Mailing List'
>Subject:	Updates for ERROR after WG last call
>
>These are the changes that I'm looking at, after the comments received
>during WG last call.
>
>Section 2.1, second bullet:
>
>Was:
>
>      - During slow start, the sender increases its window in
>        units of segments. This is why it is important to use an
>        appropriately sized MTU - and less reliable link layers
>        often use smaller MTUs.
>
>Suggested:
>
>      - Less-reliable link layers often use small link MTUs. This slows
>        the rate of increase in the sender's window size during slow
>        start, because the sender's window is increased in units of
>        segments. Small link MTUs alone don't improve things unless
>        Path MTU discovery is also used to prevent fragmentation.
>        Path MTU discovery allows the most rapid opening
>        of the sender's window size during slow start, but a number of 
>        round trips may still be required to open the window completely.
>
[snip]

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.

(This can be perceived from the ADVICE draft formula:

          MSS    1
BW = 0.93 --- -------
          RTT sqrt(p)

where p is the packet loss rate. If we assume that 

p = MSS * BER (of the ERROR link)

we see that BW is proportional to sqrt(MSS). All this is of 
course simplifications but it hold true for reasonable values.)

So what conclusions are there? One is to advice link layer designers
to consider the ADVICE formula and not only optimise link layer 
transmission without knowing the implications on TCP. 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). These are however 
advice for link designers and I do not know if this paper also 
addresses them (these issues are crucial so I wouldn't mind a 
repetition though).

The conclusion from e2e point of view of the first two sentences of
the suggested bullet is to NOT use PMTU discovery or put a lower
limit to it. But that would be antisocial competition for resources.
If this draft is intended for e2e designers, I suggest that the bullet 
is removed since I can only see implications in this direction from 
e2e point of view.

/Jan Kullander

---

From: Lloyd Wood <[email-masked]>
Date: Wed, 13 Sep 2000 16:45:17 +0100 (BST)

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

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.

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

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

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.

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

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

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