Subject: I-D ACTION:draft-ietf-pilc-link-design-03.txt

From: [email-masked]
Date: Wed, 19 Jul 2000 06:35:30 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Performance Implications of Link Characteristics Working Group of the IETF.

	Title		: Advice for Internet Subnetwork Designers
	Author(s)	: J. Touch, M. Montpetit, J. Mahdavi,
                          G. Montenegro, D. Grossman, G. Fairhurst
	Filename	: draft-ietf-pilc-link-design-03.txt
	Pages		: 21
	Date		: 18-Jul-00
	
This document provides advice to the designers of digital
communication equipment, link layer protocols and packet switched
subnetworks (collectively referred to as subnetworks) who wish to
support the Internet protocols but who may be unfamiliar with the
architecture of the Internet and the implications of their design
choices on the performance and efficiency of the Internet.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pilc-link-design-03.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pilc-link-design-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-pilc-link-design-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Reiner Ludwig <[email-masked]>
Date: Wed, 19 Jul 2000 16:52:33 +0200

thanks to the authors for the well written draft!

Some comments below.

///Reiner

1. The subnetwork's retransmission persistency:

A subnetwork's retransmission persistency, i.e., for how long should a link 
layer delay (e.g., in terms of milliseconds) an IP packet in an attempt to 
transmit it over the link before it discards the packet, is an important 
issue for subnetwork designers. However, I feel that the draft is too fague 
on this matter:
"It is important to recognize that a
    subnetwork can go too far in attempting to provide error recovery
    services in the Internet environment.  Subnet reliability should be
    "lightweight", i.e., it only has to be "good enough", *not* perfect."

A more concrete alternative would be to say something along the following 
lines:

Subnets that do not distinguish between delay sensitive (e.g., real-time or 
streaming multimedia) and reliable flows (e.g., TCP, Reliable Multicast) 
should implement a low retransmission persistency (on the order of a few 10 
milliseconds) [IS95] [GSM]. This is necessary to not interfere with the 
delay requirements of delay sensitive flows. On the other hand, subnetworks 
that are capable of separating reliable flows should implement a high 
retransmission persistency for such flows. However, a single IP packet may 
never be delayed by more than the Maximum Segment Lifetime (MSL) of 240 
seconds defined for TCP [RFC1122].

2. Minor detail in the section on "How TCP Works":

There is says: "Queues provide output-buffering on links that are 
momentarily oversubscribed."
However, queues also provide input-buffering on links and in fact packets 
can get dropped there, too, when the host/router is at high processor load.

3. Recovery from Subnetwork Outages:

To the sentence: "If it cannot
    do this, then the subnetwork should hold onto at least some of the
    packets it accepts during an outage and attempt to deliver them when
    the subnetwork comes back up.", I propose to add the following sentence:

However, none of such packet may be held for more than the Maximum Segment 
Lifetime (MSL) of 240 seconds defined for TCP [RFC1122].

Instead of the sentence: " Note that it is *not* necessary to avoid any and 
all packet drops during an outage.", I propose the following refinement:

As long as the queue management policy allows (never queue packets without 
reasonable bounds, e.g., not more than a common bandwidth*delay product) 
the subnetwork should avoid dropping any packets. Beyond that it should 
start dropping from front to give an early congestion signal to the TCP sender.

4. The "Quality of Service, ..." section

Although, I very much like the section and wish we could really implement 
it that way, I don't understand the discussion about the TOS field [RFC1349].

The definitions of the TOS field are obsolete and have been replaced by the 
definition of the differentiated service field [RFC2474 (proposed standard)] :-(

---

From: Lloyd Wood <[email-masked]>
Date: Wed, 19 Jul 2000 17:08:37 +0100 (BST)

On Wed, 19 Jul 2000, Reiner Ludwig wrote:

> issue for subnetwork designers. 

link != subnetwork...

> However, I feel that the draft is too fague 
> on this matter:

how would you recommend that such subnetworks distinguish between
these two reliably? Aren't 'delay-sensitive' and 'reliable' entirely
orthogonal criteria? (this leads into a discussion of how e.g.
diffserv specifications of same could be interpreted by the subnet -
arguably out of scope, but see discussion of QoS below.)

> retransmission persistency for such flows.

hey, that would really kill TCP over satellite's performance; RTT
estimates would be thrown right off. Practically, you're getting in
the way of the ramifications of the end-to-end argument; a lot more
careful text would be needed here.

Or, if we can't come up with text that is careful enough (discussing
subnet error rates and contrasting those with the high reliability
expected by IP-based transports in the light of delay overhead
tradeoffs incurred by the subnet), we opt for saying as little as
possible, above.

(there's some relevant text at the end of the
  'Analysis of Link Layer Effects on TCP Performance'
section that could IMO do with moving here.)

> definition of the differentiated service field [RFC2474 (proposed standard)] :-(

This was discussed on the mailing list some time back; did
the material get lost in editing? dan's on the author list...

See the thread starting 
http://pilc.grc.nasa.gov/pilc/list/archive/0774.html
and in particular Dan Grossman's text
http://pilc.grc.nasa.gov/pilc/list/archive/0803.html
(which probably needs updating/trimming, the way diffserv terminology
is going...)

Other stuff:

Referencing/discussing ramifications of Bennett's ToN paper in the
packet reordering section seems like a good idea.
'Packet Reordering is not Pathological Network Behavior' Bennett,
Partridge, Sheetman, IEEE/ACM Transactions on Networking,
December 1999, (7):6, pp. 789-798

  Examples of such subnetworks include
  ATM, with a single frame size of 48 bytes plus a 5-byte header,
 
having already referenced AAL encapsulation etc, this example sits
oddly - especially since you're talking about AAL5 several paras
later.

TCP-friendly needs a reference discussing throughput considerations
when first mentioned, and explicitly relating to the 1/sqrt(p) eqn.

   Since ACKs are generally smaller than data
   segments, TCP can tolerate some asymmetry, but as a general rule
   designers of subnetworks should avoid large differences in the
   incoming and outgoing bandwidth.

This only becomes a problem when the forward sending: backchannel acks
capacity ratio exceeds 50:1 [*], but it's worth pointing out that
assumptions about which way TCP is flowing are often invalidated by
pesky users. (Hence ADSL networks banning webservers, napster serving 
etc.)

[*] R. C. Durst, G. J. Miller, E. J. Travis 'TCP extensions for space
    communications', Mobicom '96, Nov '96 - yesyes, conference
    papers are not easily obtainable and not much point in referencing
    in an RFC - that goes for the MONET paper too.

   Using the delayed acknowledgment mechanism {Bra89], which reduces
   the number of ACKs transmitted by the receiver by roughly half, can
   also improve performance by reducing the congestion on the ACK
   channel. These mechanisms should be employed in asymmetric
   networks.

Actually, delacks are recommended use anyway; not much point in giving
endhost hints to subnetwork designers who can't control their
endhosts.

   The other *criterion* for native multicast *is* a link-layer
   filter,

   References of the form RFCnnnn are Internet Request for Comments
   (RFC) documents available online at www.rfc-editor.org.

little point in saying this _in_ an RFC. "Here's how to get this
document you're already reading".

[APS99] should be [RFC2581]

'Security' section is before references, 'Security Considerations' is
after. odd.

cheers,

L.

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

---

From: Reiner Ludwig <[email-masked]>
Date: Thu, 20 Jul 2000 14:32:21 +0200

At 17:08 19.07.00 +0100, Lloyd Wood wrote:
>these two reliably?

Good question. The protocol-ID field in the IP header can be used as an 
approximation to at least separate TCP flows from the rest. However, this 
has some problems:
- IPsec overwrites the proto-ID field, and
- other reliable flows (NFS, Reliable Multicast) run on top of UDP and can 
thus not be identified as reliable flows.

It would be so much better to have the old TOS definitions deployed ... 
which unfortunately is not the case.

>Aren't 'delay-sensitive' and 'reliable' entirely
>orthogonal criteria?

Not when it comes to the question about how persistent link layer ARQ 
should be.

>hey, that would really kill TCP over satellite's performance;

I don't believe that. Has it ever been shown?

>RTT
>estimates would be thrown right off.

Clearly, the measured RTT may vary more than without link layer ARQ. But 
that's what it should do for such a path because it only reflects the true 
RTT for sending packets reliably e2e. It will lead to a more conservative 
RTO which is exactly what should happen on such a path. Also, note that the 
RTO will drop quite sharply back closer to the "real RTT" after a sudden 
RTT spike so it's not a real problem.

BTW, the draft's proposal to counter link outages (holding on to packets 
until after the outage and then to forward them) is basically the same 
thing as highly persistent link layer ARQ. That mechanism will also cause 
considerable RTT spikes. I don't see a problem with that. It merely 
reflects the path's properties.

///Reiner

---

From: Dr G Fairhurst <[email-masked]>
Date: Thu, 20 Jul 2000 14:01:13 +0000

> > retransmission persistency for such flows.

--- or should we say "better" reliability scheme (a higher persistence is one
option, BUT too high is still dangerous - additional FEC is another option,
hybrid ARQ/FEC schemes are also suitable in some environments, ...).

> tradeoffs incurred by the subnet), we opt for saying as little as

It may be difficult to convince me that this document should start proposing
specific solutions, if we do that we run the danger of giving the wrong advice.
At the moment we have advice based on many years of people researching AND
implementing these schemes.  If we move towards what is currently good research,
then we stand the risk of having to be very specific about the types of links we
are considering. I suggest we don't do that - perhaps we should once we have this
draft finished?

> December 1999, (7):6, pp. 789-798

Excellent idea - this paper at least identifies order/delay are variable
quantities in today's deployed Internet. Perhaps something derived from::

IP networks are allowed to reorder packets. Most link protocols provide in sequence
delivery when used over a single physical link, which guarantees order. Subnets with
alternate
paths do not necessarily provide ordering [Benett]., neither does IP-forwarding when
parallel processing is used [Benett].

My feeling was still that ordering was DESIRABLE, in most cases (for performance, and
expected behaviour of transport protocols). But not required in ANY.

You may disagree :-)

> endhost hints to subnetwork designers who can't control their

This could be addressed in a revised asymmetry document?

>    The other *criterion* for native multicast *is* a link-layer

I don't agree, because many of the links I have worked with have been single-hop,
and that doesn't imply you have do anything at the link layer except broadcast the
multicast packet - IP-layer filtering would work fine (if it could be done
efficiently).

I may be out-voted though :-)

See my suggestions for a revised multicast section....

(see mail to this list on : Mon, 08 May 2000 15:05:14 +0100

Perhaps it will stimulate wider discussion?

--
------------------------------
http://www.erg.abdn.ac.uk/users/gorry

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 20 Jul 2000 15:20:50 +0100 (BST)

On Thu, 20 Jul 2000, Reiner Ludwig wrote:

> >RTT estimates would be thrown right off.
> 
> RTO which is exactly what should happen on such a path. 

The TCP flow taking that path will compete with other flows of varying
length on the (congested) terrestrial part of the internetwork.

Given TCP's bias against connections with long RTTs (e.g., see 
http://www.cs.berkeley.edu/~tomh/papers/globecom98_abstract.html) this
is often a problem for bulk data transfers.

If the RTTs of flows across your subnetwork are already extremely long
relative to the majority of other flows in the internetwork, you
should think twice before making them any longer imo.

> considerable RTT spikes. I don't see a problem with that. 

A lot depends on the link delay: outage delay ratio.

L.

---

From: Kathleen Nichols <[email-masked]>
Date: Thu, 20 Jul 2000 10:04:55 -0700

Reiner Ludwig wrote:
...
> which unfortunately is not the case.

A nice thing about the redefinition of the TOS octet is
that it is certainly possible to encode whatever you
want in the DSCP.  It's more "economical" in use of
bit-patterns than the old definition. I believe that
RFC 2474 gives you enough rope to go do whatever you'd
like.

	Kathie

---

From: Grenville Armitage <[email-masked]>
Date: Thu, 20 Jul 2000 11:36:40 -0700

Reiner Ludwig wrote:
	[..]
> which unfortunately is not the case.

Elaborating on Kathie's comment, although the DSCP doesn't have
predefined QoS semantics like the old ToS byte, this isn't such a
limitation. Consider a link interface/driver that peaks into the
DSCP as an IP-aware entity. Therefore if it is part of a Diffserv
domain, it ought to be configured for Diffserv QOS just like the
diffserv routers and hosts that surround it. So the advice
to subnetwork designers is "Allow your drivers to map from DSCPs
into 'delay sensitive', etc, classes using operator configured
mappings."   (Clearly serious word mangling is required here, but
hopefully the intent is clear...)

cheers,
gja
________________________________________________________________________
Grenville Armitage                    http://members.home.net/garmitage/
Bell Labs Research Silicon Valley

---

From: Reiner Ludwig <[email-masked]>
Date: Fri, 21 Jul 2000 08:32:14 +0200

>RFC 2474 gives you enough rope to go do whatever you'd

The problem I see with the DS field is that every border router is free to 
re-write it. This might make it difficult to mark my IPsec-encoded TCP-flow 
with the QoS requirement "maximize reliability" e2e over the entire path.

///Reiner

---

From: Reiner Ludwig <[email-masked]>
Date: Fri, 21 Jul 2000 08:26:45 +0200

on this topic, I would like to draw your attention to section 4.1 
("Extending the Differentiated Service Framework") of my dissertation which 
you can fetch here 
http://iceberg.cs.berkeley.edu/papers/Ludwig-Diss00/index.html.

It discusses pretty much what you describe, Grenville.

BTW, section 4.1.4 shows measured traces of how "holding on to packets 
during link outages" works so much better than "dropping packets during 
link outages".

///Reiner

---

From: Grenville Armitage <[email-masked]>
Date: Fri, 21 Jul 2000 00:42:20 -0700

> > > which unfortunately is not the case.

To which Kathie and I have observed it is infact better now, since
the DSCP is more flexible. So which situation do you really believe
in - that its good we have the DSCP, or we ought to return to the
ToS semantics?

Also, scanning your chapter 4 there's an odd statement on p.71 where
you suggest adding four *new* DS Field values to represent
four service classes. This is not at all what I was talking about.
The service classes you discuss can be adequately supported using
the existing PHBs (and indeed, Diffserv has always clearly stated that
PHBs/DSCPs do not represent e2e service classes as classically
understood). My previous email outlined that one can make a configured
or signalled association between particular (pre-existing )DSCPs and
the 'service class' that happens to be being mapped onto said DSCPs
on a case by case (and reconfigurable) basis.

cheers,
gja

---

From: Grenville Armitage <[email-masked]>
Date: Fri, 21 Jul 2000 00:53:20 -0700

Reiner Ludwig wrote:
	[..]
> with the QoS requirement "maximize reliability" e2e over the entire path.

The DS field (DSCP) doesn't have e2e service class semantics. Expecting
it to do so in a standardized manner suggests a misunderstanding of
Diffserv. However, clearly a network operator might 'know' that they
are using certain PHBs across a certain path to support application
flows having sensitivity to latency, or loss, or whatever. Armed
with this knowledge, the operator then configures certain link
drivers to lookup the DSCP and infer desirable link characteristics.
But that's not the same as formally defining new DSCPs to have
service class semantics. DSCPs defined PHBs - scheduling and drop
precedence semantics.

cheers,
gja

---

From: Reiner Ludwig <[email-masked]>
Date: Fri, 21 Jul 2000 13:44:16 +0200

>in - that its good we have the DSCP, or we ought to return to the

What I believe in is that it would be very beneficial for "IP over 
wireless" if we could associate the TOS semantics ("minimize delay", 
"maximize throughput", "maximize reliability", etc.) or more specific 
semantics with certain DSCPs on an e2e basis.

I'm aware of the fact that the DS field (DSCP) as opposed to the TOS byte 
does *not* have e2e service class semantics. This is what I pointed out in 
my reply to Kathie.

I (as a link layer designer) would like to use a flow's DSCP *not only* to 
control scheduling and/or queue management algorithms at the network layer, 
but *also* to control link layer error control algorithms.

E.g., in 3G systems a link layer can dynamically configure many parameters 
(e.g., for FEC, spreading factor, bit rate, ARQ persistency, etc., etc.) on 
a per packet, per flow, or at least on a per flow-class basis. I.e., the 
link layer has means to greatly influence: throughput, delay, reliablity.

For that purpose, it would be extremely helpful if the IP layer (based on 
the DS field) could tell the link layer whether a particular 
packet/flow/flow-class is, e.g.,  delay sensitive or whether it is 
TCP-based bulk data. For the latter, delay is less important but throughput 
and reliability are important QoS requirements.

>four service classes.

I didn't write that they were "*new* DS Field values". I explicitly wrote 
that I borrowed from RFC1349 (Type of Service).

>This is not at all what I was talking about.
>the existing PHBs

Maybe I missed something.

How can you specify with the existing DSCPs/PHBs that a flow (more 
precisely the application on top) is best served with max throughput and 
max reliability?

>(and indeed, Diffserv has always clearly stated that
>understood).

I didn't say anything else. I only said that I wished that such e2e service 
classes could be defined. As it was possible with the TOS byte.

///Reiner

---

From: Grenville Armitage <[email-masked]>
Date: Fri, 21 Jul 2000 09:36:26 -0700

Reiner Ludwig wrote:
	[..]
> but *also* to control link layer error control algorithms.

That's quite independent of statically assigning e2e service class
semantics to DSCPs (new or otherwise). Here's a different way of stating
my suggestion: the link driver can be configured/signalled to know,
on a case by case basis, by the network operator, the service class(es)
of the traffic being mapped into a particular DSCP (AFxy, EF, CSn...),
and thereby infer the desired link error control algorithms. No new
DSCPs (or even old ones) need additional, *statically* standardized 
e2e service semantics. IMHO.

(e.g. in one person's network AF1y might be supporting loss tolerant
traffic, in another person's network AF1y is supporting delay tolerant
traffic, etc, etc.... and this is 'known' as part of the operator's
overall Diffserv network provisioning/configuration process.)

	[..]
> that I borrowed from RFC1349 (Type of Service).

http://iceberg.cs.berkeley.edu/papers/Ludwig-Diss00/chapter4_flow_adaptive.pdf
First line of p.71, you write:

"Below, we propose four new DS Field values that allow a differentiation
 between four different service classes, ..."

Perhaps I'm reading the wrong chapter 4.

cheers,
gja

---

From: Steve Deering <[email-masked]>
Date: Fri, 21 Jul 2000 10:48:26 -0700

At 12:42 AM -0700 7/21/00, Grenville Armitage wrote:
>the DSCP is more flexible.

In communication protocols, "more flexible" usually means worse, not
better, e.g., more complex, more need for configuration, more ways to
screw up, more ways to be incompatible, etc.

I'm with Reiner on this one.

Steve

---

From: Kathleen Nichols <[email-masked]>
Date: Fri, 21 Jul 2000 13:39:56 -0700

> I'm with Reiner on this one.

And that's why the old TOS definitions were so successful...

---

From: Lloyd Wood <[email-masked]>
Date: Sat, 22 Jul 2000 02:16:24 +0100 (BST)

> screw up, more ways to be incompatible, etc.

the bitter lessons of multicast?

L.

---

From: Reiner Ludwig <[email-masked]>
Date: Mon, 24 Jul 2000 12:06:41 +0200

At 13:39 21.07.00 -0700, Kathleen Nichols wrote:
> > [...]

One reason for why TOS was never successful might be that in the past there 
was maybe not strong enough a need for it. Today, I think this is very 
different.

The designers of wireless link layers could make transmission across the 
air much more efficient if they knew what kind of flow they were dealing 
with, i.e., which QoS requirements the application on top has.

Unfortunately, many wireless link layers today are one-size-fits-all and 
that can be very inefficient, causing reduced e2e performance and waste of 
radio resources (spectrum, battery power). The only escape from that - 
given that we cannot use the TOS byte - are the tricks that Vernon pointed 
out: port number sniffing, small packets = need for low latency, ... but 
sniffing tricks won't work with IPsec :-(

///Reiner

---

From: Reiner Ludwig <[email-masked]>
Date: Mon, 24 Jul 2000 11:53:29 +0200

>overall Diffserv network provisioning/configuration process.)

I do not see how that could work.

Consider this case: I use my wireless PDA to download some streaming media 
from some server in the Internet. How can the operator of the streaming 
server make sure that the DSCP of the streaming media flow has the right 
value when the flow "arrives" at the wireless access network? The "right 
value" should be one that the operator of the wireless access network 
understands as something like "this flow is delay sensitive" or even 
something that is more precise.

Even if the DSCP would not change in transit (which of course it could), 
according to your proposal every operator of a wireless access network 
could have its own definition of which DSCP stands for "this flow is delay 
sensitive". Thus, even if the DSCP would not change in transit, it would at 
least be very difficult for the operator of the streaming server to set the 
right DSCP given that there is more than one wireless access network 
operator in the world.

The problem is that the DS philosophy is not intended for such a scenario. 
The DS framework is intended for 2 bordering domains to agree on what kind 
of traffic each domain accepts to carry from the other. For that purpose 
bilateral agreements can be made including how the DS field should be 
(re-)set at the border routers. This is fine for ensuring QoS across 
domains. I believe this is a great idea and I think that the DS framework 
is a great concept, for the problem it tries to solve.

Still, I believe that the e2e semantics of the TOS byte have quite some 
value, e.g., to solve the problem outline in the example given above. I.e., 
I still see the need for *statically* standardized DSCPs with e2e service 
semantics.

///Reiner

---

From: Phil Karn <[email-masked]>
Date: Sun, 30 Jul 2000 10:46:00 -0700

>but *also* to control link layer error control algorithms.

Exactly. Information theory says there are fundamental tradeoffs
between delay and throughput, and it would be nice for the link layer
to have some guidance in making these tradeoffs.

The main parameter is the FEC interleaver blocksize. Larger blocksizes
yield better performance, especially over fading channels, but they
increase delay. So something that can tell the physical layer what
size FEC block to use would be very helpful.

[The idea that larger blocks perform better over noisy channels may
seem strange to those unfamiliar with coding theory. If you think that
larger blocks would have a larger probability of at least one error,
you're right. That's why, on *uncoded* channels, high error rates
dictate smaller blocks. But with interleaved FEC, it's not whether
there are *any* errors in the block, but whether their number exceeds
some correction limit. With uncorrelated channel errors, the number of
errors in any given block follows a binomial distribution; as
blocksize is increased, this becomes a gaussian distribution. Thanks
to the law of large numbers, the standard deviation of this
distribution increases only as the square root of the blocksize. So
the probability that the code will fail, i.e., be overwhelmed by
errors, goes to zero as the blocksize approaches infinity *provided*
that the expected number of errors in a block is within the code's
error correction capability.]

This has gotten me thinking about how TOS should really work in a
wireless link. When you think about it, the old-style qualitative TOS
bits that meant "low delay" "high throughput" or "high reliability"
are really not that orthogonal. Ultimately the *only* link/subnet
characteristic that ever really matters is LATENCY. "High throughput"
is important only insofar as it reduces latency due to queuing delay,
and "high reliability" is important only as it decreases (or avoids)
the latency of an end-to-end retransmission scheme.  In every
situation, the goal is the same: to complete a "transaction" as
quickly as possible.

This suggests that all the link layer ever *really* wants to know is
the application transaction size. Two examples:

A bulk file transfer is a single "large" transaction, i.e., one that
will take many packets to complete.  We assume that just having part
of the file is useless, so we want to finish the whole thing as
quickly as possible. And we assume the file to be much larger than the
bandwidth*delay product of the available network path, so propagation
delays have a small effect on the transaction latency.

Here the link can be allowed to operate on the data in large chunks,
e.g, by using large FEC code blocks that could possibly span many IP
packets. This will increase throughput on a noisy channel and allow
the transaction to complete more quickly -- thus reducing "latency" by
this particular application's definition.

At the other extreme, an interactive session is really a series of
"small" transactions.  Each transaction typically fits into a single
IP packet and must be delivered before the other end can continue.
The transactions may also be small relative to the bandwidth*delay
product of the available network paths.

In this case, reducing "latency" implies getting each packet out as
quickly as possible, even if it means having to use a less efficient
FEC, i.e., one with a smaller blocksize and more overhead to keep an
acceptable probability of loss.

So what about a "TOS" field that simply indicates how many IP packets
make up this application's transaction size? While the analogy isn't
perfect, think of it as a distant cousin of the TCP "push" bit, which
was originally defined to permit implementations to gain efficiency by
aggregating data when immediate delivery wasn't necessary.

I know that redefining the IP TOS fields may be beyond the scope of
our charter, but I've been mulling it over for quite some time and I
wanted to get this idea out there to stimulate some discussion because
it does connect directly to our discussion of what performance-tuning
"knobs" a link/subnetwork should provide to IP and how applications
could use them.

Phil

---

From: Kathleen Nichols <[email-masked]>
Date: Mon, 31 Jul 2000 08:18:22 -0700

Phil Karn wrote:
...
> "knobs" a link/subnetwork should provide to IP and how applications

Phil,
Since the diffserv effort has only recently redefined the IP
TOS fields and was (and is) chartered to do so, I suspect that you
are quite right that it is out of charter for PILC. On the
other hand, it may be quite resonable to define a PHB Group
in PILC. Perhaps you should first determine that what you
want to do is impossible in that framework before rechartering
PILC and deep-sixing RFCs2474/5, RFCx2597/8?

	regards,
		Kathie