Subject: Re: Correcting LINK (Advice for Internet Subnetwork Designers)

From: Phil Karn <[email-masked]>
Date: Wed, 28 Feb 2001 22:53:36 -0800

>Packet loss probability would have to be linear (or worse)
>to size; anything less would justify larger packets.

Right.

>One reason this can occur is because doubling the transport
>PDU doesn't quite double the bits on the wire. Network and link

Also right. Perhaps that's what was meant by the text I questioned? If
so, I will reword it to clarify.

Phil

---

From: Mustafa Kocaturk <[email-masked]>
Date: Thu, 1 Mar 2001 19:33:32 -0600 (CST)

Editorial comments for file draft-ietf-pilc-link-design-04.txt
follow, with important ones first.

Performance Formula (of Padhye et al):

      Explain the meaning of the resulting "performance" value.
      Add definition of BW in the list of definitions of variables.
      "Bandwidth ceiling of the Reno TCP algorithm" might be
      appropriate.

      In traffic engineering practice, the available link bandwidth
      would also need to be taken into account.

      In the simple formula, replace "0.93" by "C".  Then add a new
      line saying "where C is 0.93".

Comments on "Analysis of Link Layer Effects on TCP Performance":

      Reword the first paragraph entirely,  spelling out what
      "these links" are, and what is it that can be "figured out".

      "For C, assume 1.":  There is no "C" in any formula in the
      text.  It should probably replace "0.93" in the simple formula. 
      A fix has been provided above.

      Observation 3:

      Replace "p = O(sqrt(MSS))" by:

              "BW = C*sqrt(MSS)/(RTT*sqrt(8*BER))"

      Consider replacing "8*BER" by "bpB*BER", where "bpB" is bits per
      byte, typically 8 (or 10, for channels adding a start and a stop
      bit for each byte, such as an asynchronous serial link).  Or,
      define and use "octet error rate" instead.

"Framing ...":

      Acronym "SDU" is overloaded.
      "SDU" normally stands for "service data unit"
      in other documents on related topics.
      Replacing "SDU" by "SNDU" (to represent "subnetwork data unit")
      might prevent some misunderstanding.

"Introduction and Overview", third paragraph from the bottom:
      
      Additional example for "partial duplication of functionality in
      a lower layer":

      A redundant transmission link may also be used to achieve QoS
      differentiation by packet filtering (or label switching).

Will send more comments as appropriate.

Kind regards,
Mustafa Kocaturk
Ericsson Research @ Texas

---

From: Phil Karn <[email-masked]>
Date: Thu, 1 Mar 2001 18:16:53 -0800 (PST)

Mustafa,

I just got your note after I put up the latest draft on my web page.
I'll work on your comments later tonight or tomorrow morning.

Phil

---

From: Phil Karn <[email-masked]>
Date: Fri, 2 Mar 2001 12:18:43 -0800

>Explain the meaning of the resulting "performance" value.  Add
>definition of BW in the list of definitions of variables.  "Bandwidth
>ceiling of the Reno TCP algorithm" might be appropriate.

I've added to the list of variables:

	BW   is the maximum throughput achievable

>would also need to be taken into account.

I've added the following text:

Note that the speed of the links making up the Internet path does not
explicitly appear in this formula. Attempting to send faster than
the slowest link in the path causes the queue to grow at the
transmitter driving the bottleneck. This increases the RTT, which in
turn reduces the achievable throughput.

>Reword the first paragraph entirely, spelling out what "these links"
>are, and what is it that can be "figured out".

New wording:

Link layer designers interested in understanding the
performance of TCP their links can use these formulae.
Consider the following example:

>"For C, assume 1.": There is no "C" in any formula in the text.  It
>should probably replace "0.93" in the simple formula.  A fix has been
>provided above.

Done.

I deleted that section, as it wasn't clear to me that it was correct.

All modern dialup modems use async/sync converters, so only 8 bits/char
actually get sent over the channel. I prefer to stick with 8-bit bytes
for now.

Done. And where SDU really meant "packet", I used that word instead.

Now reads:

...redundant transmission links to improve availability or to guarantee
performance for certain classes of traffic. ...

--Phil

---

From: Mustafa Kocaturk <[email-masked]>
Date: Mon, 5 Mar 2001 11:23:56 -0600 (CST)

Thanks, Phil.

The relationship between packet size and
error rate had some value, although the original formula had to be
corrected.  I would like to clarify how.

The original formula was mistyped. Firstly, the
formula yields "BW" (not "p").  Secondly, "proportional to" should
have been used instead of "O(.)".  The latter, "On the Order of",
connotes a match in magnitude and units, which is probably not what
the author had in mind. 

In words, the concept could have been expressed as follows:

  "Performance (BW) is proportional to sqrt(PACKET_SIZE), and inversely
   proportional to sqrt(SNDU_ER), where PACKET_SIZE is size of an IP
   packet in subnetwork data units (SNDUs), and SNDU_ER is the probability
   of error in an SNDU."

This statement is subject to the same original assumptions:
mutual statistical independence of bit errors, uniformity of their
weights in packet error, and small packet error rate.

In practice, SNDU error rate is more readily measured than the bit
error rate (which can be deduced from the former).  Hence, thinking in
terms of an SNDU may be more appropriate.  But then, the same kind of
assumptions still have to be made, this time using the SNDU instead of
the bit.

I agree that asynchronous start-stop framing is stripped in all but
the simplest modems, but much more happens at that level of detail.

At the physical layer, modems transmit data in units of symbols, which
can represent anywhere from one to several tens of bits each (I figure
approximately 28 bits for high-speed voiceband).  Above the physical
layer, modems may perform HDLC-like error control framing and
compression, depending on the selected mode of communication.  For
each mode, a different SNDU type and size applies.  In paractice, I
think it is important (and hope, is sufficient) to know what the SNDU
(size and behaviour) is, to be able to optimize the throughput and
delay.

Kindest regards,
Mustafa

Phil Karn writes:

[...]
   
   Done.

   

[...]

   --Phil

-- 
Mustafa Kocaturk -- Ericsson Research @ Texas

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 5 Mar 2001 17:44:18 +0000 (GMT)

On Mon, 5 Mar 2001, Mustafa Kocaturk wrote:

> formula yields "BW" (not "p"). 

Eh? I don't see a Hz result. Jumping all the way down to physical
bandwidth entails a large number of assumptions along the way; the
original p equation is general and avoids that.

L.

>          define and use "octet error rate" instead.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: Mustafa Kocaturk <[email-masked]>
Date: Mon, 5 Mar 2001 12:15:53 -0600 (CST)

Here is the list of parameters quoted from the draft:

           BW   is the maximum throughput achievable
           MSS  is the segment size being used by the connection
           RTT  is the end-to-end round trip time of the TCP connection
           RTO  is the packet timeout (based on RTT)
           p    is the packet loss rate for the path
                (i.e. .01 if there is 1% packet loss)
           C    is 0.93.

BER is a pure number.
MSS is a pure number.
C is a pure number.

So, the part "C * sqrt(MSS) / sqrt(8*BER)" is a pure number.

RTT has units of time, say second.  So, "1/RTT" has units of Hz.

Now could you tell me the units of
 "C * sqrt(MSS) / (RTT * sqrt(8 * BER))" ?

Also, how could sqrt(MSS) give you the packet loss rate, when the
formula    p = BER * [PACKET_SIZE*8] contradicts that?
MSS is nothing but PACKET_SIZE*8.

Kindest regards,
Mustafa

Lloyd Wood writes:

   L.

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 5 Mar 2001 19:29:55 +0000 (GMT)

>            BW   is the maximum throughput achievable

maximum link capacity that can be taken, in bits/second, say.
(use of bandwidth for anything other than Hz bugs me, hence part of my
previous grumble. Still, you're just using the conventions of the
draft, so I should have shut up. sorry.)

>            MSS  is the segment size being used by the connection

maximum. bytes, but the unit is essentially of bits.

>            RTT  is the end-to-end round trip time of the TCP connection

fractions of seconds

>            RTO  is the packet timeout (based on RTT)

fractions of seconds.

>                 (i.e. .01 if there is 1% packet loss)

pure number, since it's a rate.

>            C    is 0.93.

and dimensionless? Doubt it.

> BER is a pure number.

no. bit error rate is bits/seconds. (couldn't find BER definition in
draft?)

> MSS is a pure number.

no. bits.

> C is a pure number.

Doubt it. Handy constants put in to make equations that are themselves
approximations come out right are rarely, if ever, dimensionless, but
glancing through Ott et al., I can't see why C can't be pure - okay.

(Oh, ftp.bellcore.com no longer exists. Still, not much point in 
citing explicit urls when you can get the paper out of
researchindex.com these days.)

> So, the part "C * sqrt(MSS) / sqrt(8*BER)" is a pure number.

no chance.

> RTT has units of time, say second.  So, "1/RTT" has units of Hz.

That much I cannot disagree with.

>  "C * sqrt(MSS) / (RTT * sqrt(8 * BER))" ?

C's units might be already incredibly fudged, sqrt(MSS) doesn't cancel
out sqrt(BER), and I really don't think this is meaningful. You're
expanding on a crude approximation, but your expansion, though more
detailed, is actually less useful. The added level of detail hides the
lack of a truly solid reality behind the equation, and that's imo
dangerous to the reader.

> Also, how could sqrt(MSS) give you the packet loss rate,

didn't you just point out that was a typo? I quite like 
O(sqrt(MSS)) for getting the idea across without adding any
misleading detail, and that's what I intended (but failed) to say.

> when the

actually, not quite, since that skips headers, framing etc, and the
draft points out that MSS >= PACKET_SIZE.

Hmm, a solid definition for PACKET_SIZE would be a nice addition to
the draft.

L.

---

From: Mustafa Kocaturk <[email-masked]>
Date: Mon, 5 Mar 2001 16:00:45 -0600 (CST)

I could not find a definition of BER in the draft (or in any RFC), but
in T1A1's Telecom Glossary 2K
( http://www.its.bldrdoc.gov/projects/telecomglossary2000/ ).  It says 
"bit error rate" is a deprecated term, and to use "bit error ratio"
instead.  The latter says:

    bit error ratio (BER): The number of erroneous bits divided by the
    total number of bits transmitted, received, or processed over some
    stipulated period. Note 1: Examples of bit error ratio are (a)
    transmission BER, i.e., the number of erroneous bits received
    divided by the total number of bits transmitted; and (b)
    information BER, i.e., the number of erroneous decoded (corrected)
    bits divided by the total number of decoded (corrected) bits. Note
    2: The BER is usually expressed as a coefficient and a power of
    10; for example, 2.5 erroneous bits out of 100,000 bits
    transmitted would be 2.5 out of 105 or 2.5 × 10-5.

"BER" is another overloaded acronym, meaning "basic encoding 
rule" in X.209 and some RFCs, and "bit error rate" elsewhere.

The following formula (from the draft) implicitly defines what unit
"BER" has. 

   p = BER * [PACKET_SIZE*8]

According to this, if "p" and "PACKET_SIZE" are dimensionless above,
then so is BER. 

Kindest regards,
Mustafa

Lloyd Wood writes:

   

   fractions of seconds

   fractions of seconds.

   

   

   no. bits.

   

   no chance.

   

   

   L.

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 5 Mar 2001 22:50:37 +0000 (GMT)

On Mon, 5 Mar 2001, Mustafa Kocaturk wrote re:
http://people.qualcomm.com/karn/pilc.txt

> I could not find a definition of BER in the draft (or in any RFC),
> butin T1A1's Telecom Glossary 2K
> ( http://www.its.bldrdoc.gov/projects/telecomglossary2000/ ).  It
> says  "bit error rate" is a deprecated term, and to use "bit error
> ratio" instead.  The latter says:
>

ouch. the confusion between ratio and rate needs clarifying, then.

> According to this, if "p" and "PACKET_SIZE" are dimensionless above,

I'd be a lot happier with that argument if I could get
dimensional analysis to back it up:

bits^2/packet per second  =  bits/second  * bytes/packet  * (8) bits/byte
(or bits/packet)            (or nothing)

which doesn't tie in with:

p = 1 - ([1 - BER]^[PACKET_SIZE*8])

for which the equation you quote is a later approximation in the
draft. Since the form you quote is an approximation, units are
heavily fudged; numeric value may be slightly out (but not enough to 
be useless) in such an approximation, but the units go to pieces.

[1-BER] in the more complete form and the raising of a power does
strongly suggest BER is dimensionless, though.

Since this is computed over all bits, (bytes * bits/byte) is arguably
ideal for the 'dimensionless exponent' that makes life bearable,
although PACKET_SIZE really being bytes/packet gives me pause for
thought there.

L.