Subject: Comments:draft-ietf-pilc-link-design

From: Dr G Fairhurst <[email-masked]>
Date: Mon, 08 May 2000 15:03:11 +0100

I have the following comments, based on version two of the draft:

>> Maximum Transmission Units ....

I don't know if possibly it may be useful to note that the term “segments”
is sometimes used interchangeably with “fragments”?

>> Choosing the MTU...

I feel it may be too strong to say that interactive response times
should not exceed the well-known human factors limit of 100-200ms.

I suggest you use the term “highly desirable”.

Experience with satellite links suggest that although it is highly
desirable for network paths to have delays less than this value,
a larger value does **NOT** eliminate the usefulness of such
paths for interactive applications.

>>  Framing on Connection-Oriented Subnetworks.

The section uses the term “SDU” and “PDU”.  The term SDU
(defined as “Subnetwork Data unit”) is already used in some
documents meaning “Service Data Unit”.I don’t think the two
uses of SDU are (much) different, but suggest you use only
PDU or SDU throughout.

>> TCP Performance Characteristics

In the following set of eqtns, the MSS term is wrong, since it refers only to the TCP layer:

p=1-((1-BER)^MSS*8)
BER*MSS*8<<1
p=BER*MSS*8

Actually this isn’t MSS it is is total link layer packet size
(i.e. MSS+TCPH+IPH+all link layer headers and CRC).

>> Quality of Service...

The discussion doesn’t acknowledge the terminology of
diffserv.

>> Compression

It is good to advocate payload compression at source, however there ***may*** still be some merits in link
payload compression, when the payload is not already compressed and encryption is not used.  Link compression
is a practical solution for hosts which are unaware that the path includes a subnetwork which would benefit
from compression. I wonder if this is important enough to mention?

>> Security

In addition to protecting the subnetwork itself (e.e. preventing unauthorized use), subnetwork security also
protects the link from traffic analysis by a third party monitoring a wireless bearer.

Best wishes,

Gorry Fairhurst

P.S. I've also tried a go at a better multicast session (see later email).