Subject: Current LINK snapshot available

From: Phil Karn <[email-masked]>
Date: Tue, 19 Oct 1999 00:16:01 -0700 (PDT)

Hi all. I'm still alive, and yes, I'm editing the Advice For Link
Designers document. I'm still actively editing it, but I've put my
current snapshot on my web page so you can see how it's shaping up.

The URL is http://people.qualcomm.com/karn/pilc.txt

--Phil

---

From: Dan Grossman <[email-masked]>
Date: Tue, 19 Oct 1999 15:50:19 -0400

Here are some initial comments:

1) The draft doesn't have to "market" IP to subnet designers.  Users of the 
document either will have decided to make their subnets IP friendly or not 
based on their own needs, business related and otherwise.

2) > Duplicating these functions at the lower levels is at best
   > redundant, and can even be harmful.
This is a more extreme view than suggested in "End-to-End Arguments".  Try: 
"Duplicating these functions at lower layers should be done only when a 
quantifyable performance benefit can be achieved by doing so.  Otherwise, such 
duplication is at best redundant, and at worst counterproductive."

3) > While connectionless subnetworks generally
   > provide this feature, many connection-oriented subnetworks do not.
It's not a connection oriented versus connectionless subnetwork issue.  It's 
really that for some subnets, packet framing is an integral part of the 
protocol specifications, while for others, there is a separate specification.  
I'd remove the sentence.

4) > ATM has its own framing method described in [RFC1577].
That's RFC 2684.  There's also RFC 2364, which is PPP over ATM.

5) > Because these framing methods are usually implemented partly or
   > wholly in software, performance may suffer at higher speeds.
Not true.  Designers can usually be trusted to incorporate enough hardware 
support into their devices to get adequate performance.  In the case of ATM, 
almost all implementations I'm aware of either have AAL5 in hardware or in a 
dedicated RISC processor.  PPP over serial links is usually supported with DMA 
these days, at least in the implementations I'm aware of.  There is no need 
for this statement.  

6) > [comments about common packet sizes and internal ATM wastage]
Can we avoid gratuitous ATM bashing?  Anybody working with an ATM subnet is 
quite aware that there is a certain amount of overhead associated with 
unpacking variable length packets into fixed sized cells, and has accepted 
that as a fair trade-off.

7) > (This is a very good
   > way of detecting congestion, because it happens as a by-product of
   > normal communication.  It doesn't require any special behavior from
   > hardware, and doesn't require any understanding of IP or IP headers.)
Must this document be an apolgist for TCP?  TCP is as it is for historical 
reasons, not because the state of the art has not advanced over the past 14 
years.  For better or worse (worse), the semantics of packet loss are 
overloaded, and there is a performance penalty associated with that in the 
case of lossy subnets.  Were it possible to start from scratch, I would prefer 
to think there would at least be explicit congestion notification, and perhaps 
an explicit indication of the TCP connection's fair share of the bottleneck 
rate. 

8) > A new technique called "Explicit Congestion Notification" (ECN)
   > allows routers to directly signal congestion to hosts without
   > dropping packets.
If it weren't Experimental, I'd suggest that there be a Recommendation that 
ECN (RFC 2481) be implemented at routers at the endpoints of dynamically 
variable rate and/or lossy subnets.  We should at least mention this as a 
possible performance enhancement if the subnet designer thinks there's any 
chance at all that the subnet will be used by an ECN-reactive TCP.

9) > Buffering, flow & congestion control
Should the draft Recommend that if the subnet has queueing and discarding, 
that it implement some form of active queue management (e.g., RED)?

10) > [atm dropping individual cells in a packet means the entire packet
   must be dropped]
Early packet discard and Partial Packet Discard are both well known 
requirements to the ATM community.  There probably should be a recommendation 
that IP over ATM implementations use EPD/PPD.   The correct reference is to 
the ATM Forum Traffic Management 4.1 specification (www.atmforum.com).

---

From: Jamshid Mahdavi <[email-masked]>
Date: 20 Oct 1999 14:21:28 -0700

Heh...  In http://people.qualcomm.com/karn/pilc.txt:

  "However, we recommend that subnetworks should attempt to
   gratuitously re-order segments."

I think there is a "not" missing!  But it is quite amusing :-)

--J

---

From: Jamshid Mahdavi <[email-masked]>
Date: 20 Oct 1999 14:53:16 -0700

Dan Grossman <[email-masked]> writes:

>    > way of detecting congestion, because it happens as a by-product
>    > of normal communication.  It doesn't require any special
>    > behavior from hardware, and doesn't require any understanding
>    > of IP or IP headers.)
>
> Must this document be an apolgist for TCP?  TCP is as it is for
> historical reasons, not because the state of the art has not
> advanced over the past 14 years.  For better or worse (worse), the
> semantics of packet loss are overloaded, and there is a performance
> penalty associated with that in the case of lossy subnets.  Were it
> possible to start from scratch, I would prefer to think there would
> at least be explicit congestion notification, and perhaps an
> explicit indication of the TCP connection's fair share of the
> bottleneck rate.

Well, I wrote that paragraph, so I'll take the credit :-).  I actually
believe this statement, and am not using it to justify why TCP works
the way it does.

I had a discussion a while back which started out with the question
"Is it easier to change the end-hosts or the routers?".  It doesn't
really matter what we were talking about changing -- I can't even
remember.  The obvious answer is, of course, the routers, because
there are many fewer of them than end-hosts.

However, for things like congestion control, it isn't *just* the
routers that matter.  What you really need to change is the fabric of
the network.  Since this includes all sorts of things -- routers,
bridges, switches, modems, and all manner of frightful mutant
variations, there is much more to it than just "change the routers".

As an example of this, Path MTU discovery came out a nice long time
ago.  There is a nice, clear description of how to implement it, yet
there are still all sorts of problems with actual implementation in
the network.  For example, FDDI to Ethernet bridges need to know to
send ICMP can't fragment in response to larger than 1500 byte FDDI
packets being sent to an ethernet host.  Well, big surprise, some of
them don't do this.  (Read draft-ietf-tcpimpl-pmtud-02.txt for more
examples of such problems).

The magical thing about the Internet is that it is a network of
networks.  You can plug *anything* which can send datagrams in and
make it part of the Internet just by building a suitable router for
it.  And, pretty much, this is precisely what has happened.

So, my answer to the question is: it is easier to change the hosts.
Maybe I think this because if there is a host problem, there are only
two (yours and theirs), and not 12 routers, 29 bridges, and a T3 line
with clock-slips (or misconfigured packet sizes, or whatever) in
between.  I can debug a problem with 2 possible sources.  It is much
harder to call the guy from foo.net, and ask them if they have any
FDDI to Ethernet bridges, and then ask them what vendor they are, and
if they support Path MTU discovery, (you get the idea) possible for
every provider along a path.

Mapping this all back to my paragraph in the LINK document, I really
believe what I wrote.  Suppose we put in mandatory congestion
notification.  If we do it via ICMP (like source quench), does it get
blocked out by misconfigured firewalls?  If we include it in the
packet, where does it go?  Has to be IP, because there is no way you
can expect everything to dig into a layer 4 header (which, by the way
might not even have space for it -- i.e. UDP).  Even with the bits for
ECN put in at the IP header, can your ATM switch set the appropriate
bit in the IP header, even when it decides there is congestion after
the first cell of the packet (carrying the header) has gone by?  Does
your ethernet switch set the ECN bits?  How about shared media where
the congestion might occur on the wire (or in the air) itself and not
actually happen in a device which can be programmed?

Ultimately, the one thing you can count on is that if something goes
wrong, a packet *will* get dropped.  (This does make an argument
against devices with infinite buffering, but most people don't
accomplish that feat be accident...)

As a side note, this doesn't mean that I don't approve of ECN or other
similar ideas; I just don't believe we can ever expect them to fully
eliminate packet loss as a sign of congestion.

Sorry for the long diatribe -- I don't mean to sound like I'm jumping
on you or anything.  I have been thinking about this for a while and
am quite curious how people will react to it.  Flame away :-)

--Jamshid

---

From: Mikael Degermark <[email-masked]>
Date: Thu, 21 Oct 1999 14:00:34 +0200

Comments on LINK:

Page 3:

   Subnetworks may, but are not required to indicate the lengths of the
   packets they carry.  One example is Ethernet with the DIX (not IEEE
   802.3) header, which lacks a length field to indicate the true data
   length when the packet is padded to the 60 byte minimum.  This is not
   a problem for IP because it carries its own length field.

All schemes I know about that do header compression relies on the length
information being there. It does not have to be explicit, it is sufficient
that the 
network interface can indicate the length of the frame.

Perhaps one could add: 
For header compression purposes, however, it is required that the link
framing 
can provide the length information, be it explicitly or implicitly, as that
is needed
for the reconstruction of the original header.

---

From: Dan Grossman <[email-masked]>
Date: Thu, 21 Oct 1999 14:36:19 -0400

Jamshid,
First of all, I prefer to think that we can conduct a meaningful discussion 
without flaming.  Also, this is slightly off topic, and I don't want to launch 
a long debate on this list.

The underlying issue is a philosophical difference.  Your note suggests that 
the greatest good is in expediency:  an architecture is good if it's easy to 
deploy.  My view is that architecture should be driven by architectural 
principles first, and ease of deployment should only be one of a number of 
considerations. 

A view of history (which some who were there might consider revisionist): 
during the early development of IP, issues surrounding congestion and 
real-time resource management were not given adequate consideration.  ICMP 
source quench was an afterthought, and its semantics and expected behaviors 
were not well defined.  Frankly, at the time, the connectionless versus 
connection oriented religious wars were beginning to heat up, and research 
into congestion was (in many people's minds) too closely identified with the 
heavyweight mechanisms in X.25.  It wasn't until the congestion collapses of 
1983-84 that congestion came to be taken seriously by the ARPAnet community.  
And at that time, the question was: do we change the routers, or do we change 
the hosts, because it was too much work to do both.  And the answer was:  we 
change the hosts, because it's easier.  Thus, Nagle's Algorithm led to slow 
start and congestion avoidance as we know it today.  And thus the current 
cycle of tinker, simulate, deploy, then tinker some more.

There were a number of things we know now that we didn't know then.  The 
Internet has several orders of magnitude more hosts and more routers.  And 
what seemed pragmatic at the time pales in significance now that few if any of 
those early 1980s-vintage routers and hosts are still deployed.

More to the point, the functional partitioning between IP and TCP does not 
reflect architectural principles for functional partitioning.  Stevens, Myers 
and Constantine observed in the mid-1970s that  functions should be 
partitioned into functional groupings that have strong internal cohesion and 
weak external coupling.  The underlying architectural problem with the way we 
presently manage congestion is that congestion concerns resources (queues and  
bandwidth offered by the subnet) in the IP layer, yet we attempt to control it 
using mechanisms in the TCP layer.  Thus, strong coupling between TCP and IP, 
and a bunch of functions in TCP which are not really cohesive with end-to-end 
reliable delivery.  I believe that this is the root cause of many of the 
problems we see in PILC, E2E, in the dark forebodings on Sally Floyd's home 
page and elsewhere.

Another architectural principle is that overloaded semantics is to be avoided, 
particularly if there is no  way to disambiguate semantics based on context.  
Again, the semantics of a packet loss is overloaded and is very difficult to 
disambiguate: it can either be congestive or errored.  And this is the sole 
cause of the problems that PILC is trying to solve in the 'Errored' draft.

If we could redo everything, I believe it would end up looking somewhat like 
the ATM available bitrate service category.  Not to say that's perfect.  But 
in an ideal world, we would want to give 'best effort' and 'better than best 
effort' IP some of its properties:  placement of the entire control loop in a 
single layer, effective avoidance of congestive loss, isolation between flows, 
allowing aggressive and sociopathic flows to be disciplined, less sensitivity 
than TCP to subtle implementation details, ability to conveniently segment the 
control loop if necessary without breaking end-to-end semantics, restricting 
the slow start period to 1 RTT, prompt (not much more than an RTT) adjustment 
of the transmit rate to the flow's fair share of the bottleneck bandwidth.  

Of course, this is moot.  As a practical matter, we aren't going to be able 
completely re-roll the IP infrastructure and millions of hosts. There is cause 
for doubt that we will even succeed in driving a far less ambitious transition 
to IPV6, much less such a significant architecture shift.

In another words, we are constrained by history to continue to tinker, 
simulate and deploy TCP tweaks and network discard policies.  And we are 
condemned to live with performance problems that directly result from 
fundamental properties of the architecture.

I don't suggest that we ought to say all this in the 'Advice' draft.  But at 
least we ought not to claim that what we have is as good as it could be if we 
were starting from a clean sheet of paper.  It is quite sufficient for the 
draft to say that Internet protocol suite is what it is, and link designers 
who wish to take advantage of its ubiquity and the connectivity of the 
Internet need to take the vagaries of the Internet protocol suite into account.

We should keep the philosophical discussion on the PILC list to a minimum -- 
I'm sure that Aaron and Mark will squelch it when it goes to far afield.  
Flames to /dev/null.  And I'm not expecting the Spanish Inquisition :-).

Dan

---

From: Phil Karn <[email-masked]>
Date: Thu, 21 Oct 1999 12:20:39 -0700

Hi Dan,

You make some good points. I'm still editing the text, and I'll work them in
as best I can.

Phil

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 21 Oct 1999 17:04:15 -0400

> that the network interface can indicate the length of the frame.

Indeed, i once had a fun time tracking down a header compression bug
when a packet being forwarded from ethernet to ppp didn't get the
excess ethernet frame padding chopped off...

> For header compression purposes, however, it is required that the
> link framing can provide the length information, be it explicitly or
> implicitly, as that is needed for the reconstruction of the original
> header.

Hmm.  That seems overly restrictive, as alternate header compression
algorithms could avoid squishing out the length ..

Here's a different wording..

"Note, however, that most header compression algorithms [rfc1944, ...]
rely on the underlying connection-oriented subnetwork to provide an
exact end-of-frame indication to allow them to remove the redundant ip
length field from the packet."

---

From: Phil Karn <[email-masked]>
Date: Thu, 21 Oct 1999 14:25:25 -0700 (PDT)

>algorithms could avoid squishing out the length ..

I addressed this as follows:

Subnetworks may, but are not required to indicate the lengths of the
packets they carry.  One example is Ethernet with the DIX (not IEEE
802.3) header, which lacks a length field to indicate the true data
length when the packet is padded to the 60 byte minimum.  This is not
a problem for IP because it carries its own length field.  If VJ
[RFC1144] header compression is used, however, it is required that the
link framing can provide the length information, be it explicitly or
implicitly, as that is needed for the reconstruction of the original
header.

--Phil

---

From: Phil Karn <[email-masked]>
Date: Thu, 21 Oct 1999 13:46:24 -0700

>For header compression purposes, however, it is required that the link framing 
>can provide the length information, be it explicitly or implicitly, as that is needed

Good suggestion; I added it.

Phil

---

From: Jamshid Mahdavi <[email-masked]>
Date: 21 Oct 1999 14:25:50 -0700

Well, until Mark and Aaron squelch us, I'll continue the discussion,
because I think it is pretty interesting :-)

First off, no major complaints about your history.  This next
paragraph is probably where my biggest disagreement is:

> More to the point, the functional partitioning between IP and TCP
> does not reflect architectural principles for functional
> partitioning.  Stevens, Myers and Constantine observed in the
> mid-1970s that functions should be partitioned into functional
> groupings that have strong internal cohesion and weak external
> coupling.  The underlying architectural problem with the way we
> presently manage congestion is that congestion concerns resources
> (queues and bandwidth offered by the subnet) in the IP layer, yet we
> attempt to control it using mechanisms in the TCP layer.  Thus,
> strong coupling between TCP and IP, and a bunch of functions in TCP
> which are not really cohesive with end-to-end reliable delivery.  I
> believe that this is the root cause of many of the problems we see
> in PILC, E2E, in the dark forebodings on Sally Floyd's home page and
> elsewhere.

If the resources (queues and bandwidth) were actually all in the IP
layer, I might be swayed.  But I've seen an awful lot of cases (and
can imagine many, many more) where bad things happen within the link
layer -- resources which could only be "part of the IP layer" if the
link layer devices understood they were part of an IP network.

(Perhaps to quickly jump to a conclusion of the discussion: 1. we
should put some of the spirit of this conversation into the draft, and
2. we should identify what things link layers should do to be nice to
a far-future version of IP which does have the characteristics you
describe.)

> Another architectural principle is that overloaded semantics is to
> be avoided, particularly if there is no way to disambiguate
> semantics based on context.  Again, the semantics of a packet loss
> is overloaded and is very difficult to disambiguate: it can either
> be congestive or errored.  And this is the sole cause of the
> problems that PILC is trying to solve in the 'Errored' draft.

To play devils advocate: how often is an error a sign of congestion?
The guys who want to do UDP-lite might like a version of ATM AAL5
which filled in missing cells with 0's but sent the packet on.
Checksum fails, packet has an error, but it is fundamentally due to
congestion.  Granted, this is stilted, but I believe you could come up
with similar examples in the wireless world and perhaps even in the
shared ethernet world.

It would be great if we could eliminate the overloading, but I can't
imagine how it will happen.  Maybe if ECN or something like it were
widely deployed, we could choose a different congestion algorithm than
AIMD for packet loss -- one which wouldn't have as much penalty for
pure errors -- and make the world better (but not perfect) for links
with errors.  (Actually, this is something that is needed sooner
rather than later; really high-speed links with non-zero error rates
get destroyed by TCPs current performance.  I believe we can solve the
current problems for wireless, because the bandwidth is pretty low.
At high speeds, even 1E-6 packet loss can be too high...)

> If we could redo everything, I believe it would end up looking
> somewhat like the ATM available bitrate service category.  Not to
> say that's perfect.  But in an ideal world, we would want to give
> 'best effort' and 'better than best effort' IP some of its
> properties: placement of the entire control loop in a single layer,
> effective avoidance of congestive loss, isolation between flows,
> allowing aggressive and sociopathic flows to be disciplined, less
> sensitivity than TCP to subtle implementation details, ability to
> conveniently segment the control loop if necessary without breaking
> end-to-end semantics, restricting the slow start period to 1 RTT,
> prompt (not much more than an RTT) adjustment of the transmit rate
> to the flow's fair share of the bottleneck bandwidth.

I certainly wouldn't mind seeing more function in the network than
just the single ECN bit.  I've seen several proposals for ways to do
this, and I agree with you that we can do a lot better.  And I even
believe we'll get there.  But I think I'll continue to believe that
the place most of the work will be done is in the transport layer, not
the IP layer.

--J

---

From: Phil Karn <[email-masked]>
Date: Thu, 21 Oct 1999 13:50:11 -0700

>eliminate packet loss as a sign of congestion.

So we're back to the original end-to-end principle, I guess. The
ultimate responsibility for many things must lie at the end points,
but that doesn't rule out doing things at lower layers as performance
enhancements.

Phil

---

From: Dan Grossman <[email-masked]>
Date: Thu, 21 Oct 1999 19:23:19 -0400

> link layer devices understood they were part of an IP network.
Sure, there are resources in multiple layers. The point is that you want to 
have each layer manage its own resources, rather than relying on another layer 
to do resource management on its behalf. The lower layer admits data (what the 
OSI folks used to call 'service data units') from the higher layer based on 
its available capacity.  Any longer-term congestion ripples backwards up the 
protocol stack, across a simple layer service interface. I would argue that 
this is loose coupling.

> a far-future version of IP which does have the characteristics you
I hadn't thought about it.  I'm not quite sure how it would fit, or serve the 
purposes of the document,  but wouldn't mind contributing.

> with similar examples in the wireless world and perhaps even in the
AAL5 discriminates between bit errors and lost cells, because of the length 
field.  In addition, RFC 2684 requires turning off the errored delivery option 
in AAL5, which was really put in for the benefit of error concealment in MPEG 
over AAL5 receivers, on the theory that some bad bits are better than none. As 
far as wireless is concerned, I'm no expert (and you'd better believe my place 
has _real_ wireless experts!), but tend to doubt they'd choose to interfere 
rather than queue and drop.
> the place most of the work will be done is in the transport layer, not
I think we're agreeing violently that it will happen in the transport layer, 
for better or worse.  The observation was that were a different functional 
partitioning selected, we could do much better.

---

From: Mikael Degermark <[email-masked]>
Date: Fri, 22 Oct 1999 14:37:42 +0200

To my knowledge, no header compression scheme in the IETF keeps the 
length information. 

>excess ethernet frame padding chopped off...

Clearly an errouneous implementation! In RFC2507, for example, it is clearly 
stated that if there is such padding, between IP and frame or between UDP and
frame, header compression cannot be applied.

>length field from the packet."

This wording assumes that header compression is only done over 
connection-oriented subnets. That is overly restrictive.

Micke

---

From: Phil Karn <[email-masked]>
Date: Fri, 22 Oct 1999 09:59:21 -0700 (PDT)

>frame, header compression cannot be applied.

In my own IP router implementation, I wrote code that would truncate
each incoming IP datagram to the length specified in the header. This
took care of Ethernet, plus any other subnet that might someday do the
same kind of padding. Then there was no problem compressing these
packet headers on the way back out.

Phil

---

From: Phil Karn <[email-masked]>
Date: Fri, 22 Oct 1999 10:01:08 -0700 (PDT)

>connection-oriented subnets. That is overly restrictive.

I agree that the wording may be unnecessarily restrictive, but it is
true that header compression is usually done over connection-oriented
networks. Header compression assumes certain semantics that are not
usually provided by connectionless networks, such as at-most-once,
sequenced delivery. VJ header compression quickly breaks when you
reorder or duplicate compressed frames. Or drop them too often, for
that matter.

Phil

---

From: Mikael Degermark <[email-masked]>
Date: Fri, 22 Oct 1999 19:41:19 +0200

>reorder or duplicate compressed frames. Or drop them too often, for

Agree with your statements about in-sequence, etc.

I still think that the wording should not be "connection-oriented" as
that is somewhat misleading. If we want to get into this, we 
should instead talk about at-most-once, sequenced, not-drop-too-often,
since that, as opposed to connection-orientation, is what is important.

I wouldn't say that PPP is connection-oriented, exactly. Still, most header
compression is done over PPP or SLIP. The underlying bearer of the bits,
however, is of course connection-oriented for PPP and SLIP.

Micke

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 22 Oct 1999 13:45:54 -0400

> > Clearly an errouneous implementation! In RFC2507, for example, it is
> >clearly stated that if there is such padding, between IP and frame
> >or between UDP and frame, header compression cannot be applied.
> 

Indeed -- the problem i wound up debugging arose when someone else
added an excessively optimized "fast path" which skipped a bunch of
the usual processing, one of which was the truncation of the packet to
the length in the ip header.  Putting the packet truncation code back
into the fast path fixed the problem..

					- Bill

---

From: Phil Karn <[email-masked]>
Date: Fri, 22 Oct 1999 11:21:18 -0700 (PDT)

>however, is of course connection-oriented for PPP and SLIP.

Right, and that's what maintains the in-order semantics assumed by VJ
header compression. I'll work up some appropriate text.

Phil

---

From: Phil Karn <[email-masked]>
Date: Fri, 22 Oct 1999 11:24:38 -0700 (PDT)

Here's the text I put in. Look OK?

If optional VJ [RFC1144] header compression is used, however, it is
required that the link framing indicate frame length as it is needed
for the reconstruction of the original header.

--Phil

---

From: Mikael Degermark <[email-masked]>
Date: Fri, 22 Oct 1999 20:44:12 +0200

At 11:21 AM 99/10/22 -0700, Phil Karn wrote:
>header compression.

... and also assumed by all other header compression schemes
I know about such as RFC 2507, RFC 2508, and the new ROCCO 
(draft-jonsson-robust-hc-xx.{ps,txt})

Micke

---

From: Mikael Degermark <[email-masked]>
Date: Fri, 22 Oct 1999 20:47:47 +0200

>for the reconstruction of the original header.

I think there should be references to
RFC 2507 (IP header compression), and 
RFC 2508 (RTP/UDP/IP header compression) as well, given that they
are Proposed Standards!

---

From: Phil Karn <[email-masked]>
Date: Fri, 22 Oct 1999 12:36:44 -0700

>RFC 2508 (RTP/UDP/IP header compression) as well, given that they

Done. Since it's only about 1.5 hours to the deadline and I have a
doctor's appt coming up, I'm about to update the current snapshot on
my webpage and also submit it to the Internet Drafts coordinator.

I'll keep working on the document, though, and continue to post snapshots
on my web page.

http://people.qualcomm.com/karn/pilc.txt

Phil

---

From: Dan Grossman <[email-masked]>
Date: Mon, 25 Oct 1999 13:50:09 -0400

> purposes of the document,  but wouldn't mind contributing.
I thought about it over the weekend.

This doesn't seem to fit with the Link draft.  However, it would be interesting to do an Informational draft describing the functional characteristics of a hypothetical TCP and IP that were designed to be link friendly.  This takes exactly the opposite approach from the Link draft, which takes TCP and IP as a given, and describes the characteristics of a TCP and IP friendly link.

Obviously, this would be of far less practical interest, since the likelyhood of replacing the existing TCP and IP anytime soon is vanishingly small.  On the other hand, such a draft might be interesting from a research perspective.  It might also help us understand why problems surrounding anomalous links are so difficult.

It's not clear to me that such a draft is in scope, or how much interest there might be in having one.  Aaron/Mark?

If there is a decision to go ahead with such a draft, would anybody else be interested in contributing ideas?  Jamshid?

---

From: Steve Deering <[email-masked]>
Date: Mon, 25 Oct 1999 16:08:18 -0700

At 10:01 AM -0700 10/22/99, Phil Karn wrote:
>networks.

Phil,

A common use of VJ header compression is (or at least was at one time)
on an RS-232 serial cable directly connecting two machines (i.e., no
modems involved).  That is not a "connection-oriented network", any more
than is an Ethernet cable with two nodes attached.

Steve