Subject: RE: Link Layer designers draft...

From: "Brooker, Ralph" <[email-masked]>
Date: Fri, 23 Jul 1999 10:34:58 -0500

Jamshid, this is an excellently written summary.  A few suggestions:

In note 2, add "Note that links with Forward Error Correction (FEC)
generally have very non-uniform bit error distributions.  The distribution
is a strong function of the types and combinations of FEC algorithms used.
In such cases these equations cannnot be used to apply BER to the
performance equations above and packet loss rate must be determined in other
ways." 

In note 4, the sentence "Satellite links have one-way times of about 500
msec (250 msec up and down)" is not correct.  I suggest this wording
instead:  "Satellite links have RTT's of about 500 msec (125 msec up and
down, one-way)."  Also, at the end of this paragraph, add: "Short sessions
with low BW on long-delay links are more sensitive to packet loss rate than
are long sessions.  Acceptable performance in this case might be defined as
a high probability that a session is not subjected to congestion-avoidance
slow-down during its lifetime due to an errored packet."

Regards
Ralph Brooker

-----Original Message-----
From: Jamshid Mahdavi [mailto:[email-masked]]
Sent: Friday, July 23, 1999 10:28 AM
To: [email-masked]
Subject: Link Layer designers draft...

All,

I drafted the following (large) section of text for the PILC Link
Layer designers draft which Phil is assembling.  I wanted to send it
by the list for comments, since it is long on its own and may spark
some interesting discussions/controversy.  

<snip>

Some observations on performance:

1.  We have assumed that the packet losses on the link layer are
    interpreted as congestion by TCP.  This is a "fact of life" which
    must be accepted.

2.  Note that the equations for TCP performance are all expressed in
    terms of packet loss.  Many link-layer designers think in terms of
    bit-error rate.  If there is a uniform random distribution of
    errors, then the probability of a packet being corrupted is:

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

    (Here we assume MSS is represented in bytes).  If the inequality

       BER * MSS * 8 << 1

    holds, p can be approximated by:

       p = BER * MSS * 8

    These equations can be used to apply BER to the performance
    equations above. 

3.  Note that the packet size plays an important role.  Larger packet
    sizes will allow for improved performance at the same *packet
    loss* rate.  Assuming constant, uniform bit-errors (insead of
    packet errors), a simple derivation will show that larger packet
    sizes still result in increased TCP performance.  For this reason
    (and others) it is advisable to support larger packet sizes where
    possible.  

4.  We have chosen a specific RTT which might occur on a wide-area
    Internet path within the USA.  In the Internet, it is important to
    recognize that RTT varies considerably.  In a LAN environment, RTT
    are less than 10 msec.  International connections may have RTTs of
    200 msec or more.  Modems and other slow links also have high RTTs
    due to packet transmission times.  Satellite links have one-way
    times of about 500 msec (250 msec up and down).  Heavily congested
    links may have queues which back up, increasing RTTs.  Finally,
    VPNs and other forms of encrypted tunnels add significant delay to
    network connections.
<snip>

---

From: Jamshid Mahdavi <[email-masked]>
Date: 23 Jul 1999 09:50:08 -0700

> performance equations above and packet loss rate must be determined in other

I'll go ahead and add this...  My take is that "other ways" means
understanding what the distribution of bit errors is, and applying
this in the same way I applied a uniform distribution in the example.
Or did you have something else in mind?

> slow-down during its lifetime due to an errored packet."

Aha, already some interesting discussion point :-)

Regarding the satellite links, do most people expect them to be used
in both directions?  I thought that many people were trying to deploy
asymmetric things like sending via satellite and replies via modem or
landline.  That's why I tried to use the one-way time in the comment.

Regarding the latter point, I don't believe that this is true.  I'm
assuming by "short sessions", you are talking about web connections.
If a short session takes a packet loss, particularly in the first few
RTTs, where it will result in a timeout due to lack of dupacks, I
agree that the apparent affect will be much worse (due to the
timeout).  However, if you compare (for example) 100 consecutive 10kB
"short connections" to 1 long 1 MB transfer, I think you'll see that
the 1 MB transfer is actually more affected by higher packet loss
rates.

(I'm going to go off now and do the math on this case.  I'll post the
results when I figure them out :-)

--J

---

From: "John Border" <[email-masked]>
Date: Fri, 23 Jul 1999 13:10:39 -0400

To be accurate, you need to indicate that this latency is associated with
geosynchronous (GEO) satellite links.  The latency with LEO and MEO satellite
links is significantly less...

> slow-down during its lifetime due to an errored packet."

John Border
Hughes Network Systems