Subject: Re: When non TCP/IP literate people design cable modem systems

From: Reiner Ludwig <[email-masked]> (by way of Reiner Ludwig <[email-masked]>)
Date: Wed, 23 Jun 1999 09:39:49 -0700

the included mail is cross-posted from the e2e mailing list as I think it
is also relevant for this list ....

At 05:52 AM 6/23/99 , Perry E. Metzger wrote:
>Some folks at Unnamed Cablemodem Provider have a lovely cable modem
>system that rarely drops packets, but which does appear to have
>astoundingly large queues and reliable retransmits in the data link
>layer. I'm sure they thought this was a Great Idea. [....]

I don't work with cable modems in any way but ...

... fully-reliable link layer error recovery really is a Great Idea (not
necessarily the large queues, though) provided that the link layer 
1. discriminates between TCP and UDP flows and performs fully-reliable link
layer error recovery _only_ for TCP flows (maybe also for ICMP ?), and 
2. does not delay a segment beyond the MSL of 2 minutes (which, by the way,
also serves as an upper bound for the reassembly timeout after IP
fragmentation [RFC 1122]) devided by the value of the TTL field.

(1) can be achieved by inspecting the protocol-id in the IP header. This
certainly has its limits as it does not account for reliable flows built on
top of UDP (e.g., NFS, reliable multicast). It would be much better if
reliable flows would express in the DS field the fact that they need to
provide reliablity to their applications.

(2) might sound odd but consider what happens over paths that include links
exhibiting temporary link outages (e.g., when a user roams into (and back
out of) an area without wireless connectivity in a packet radio network).
In this case all of the flow’s unacked packets will eventually be discarded
by an unreliable or less persistent (semi-reliable) link layer sender. This
will often cause an idle wait for a backed-off transport layer
retransmission timer to expire (up to 64 seconds). If, on the other hand,
packets were still queued at the (wireless) link, the end-to-end flow of
data could be re-started immediately after the link has become available
again.

The latter will most likely cause a spurious timeout which in turn forces a
go-back-N behavior in TCP but (a) that's still better than the idle wait
and (b) can be avoided with the "Eifel" algorithm
(http://iceberg.cs.berkeley.edu/papers/Ludwig-FlowAdaptive/index.html -
Section 4.5).

///Reiner

---

From: Lloyd Wood <[email-masked]>
Date: Wed, 23 Jun 1999 18:37:40 +0100 (BST)

On Wed, 23 Jun 1999, Reiner Ludwig wrote:

> ... fully-reliable link layer error recovery really is a Great Idea 

Oh, absolutely.

If there's one thing we need more of, it's X.25 deployment.

> (not
> 1. discriminates between TCP and UDP flows

Bad idea. This discrimination breaks layering and messes up extremely
badly with tunnelling. This crude discrimination assumes a lot about
delivery mechanisms and intent.

> and performs fully-reliable link

I wouldn't want to be making broad assumptions about internetwork
traffic lifetimes at the link layer. Again, that breaks layering.

> provide reliablity to their applications.

Reliability is in the eye of the beholder.

> In this case all of the flow's unacked packets will eventually be discarded

You're ignoring all the cases where the user roams out of the area and
_stays_ out of the area, so packets remain queued for no reason at
all. That queuing impacts other users, no doubt...

What you suggest above is quick delivery of reliable data; a reliable
_and_ realtime consideration. It's reasonable to assume that
higher-level protocols are quite capable of negotiating some
replacement link, in order to get their own quick, reliable delivery
back.

These per-situation local optimisations really get in the way of the
Big Picture. IMO.

> (http://iceberg.cs.berkeley.edu/papers/Ludwig-FlowAdaptive/index.html -

L.
 
> ///Reiner

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

---

From: Reiner Ludwig <[email-masked]>
Date: Wed, 23 Jun 1999 11:27:06 -0700

At 10:37 AM 6/23/99 , Lloyd Wood wrote:
>> [...]

Apparently, you are still living in the cold war of TCP/IP vs. OSI. Relax,
the war is over. 

Note, that I'm not defending OSI and certainly not X.25's hop-by-hop acking
of packets. That's a completely different topic.

>delivery mechanisms and intent.

I don't agree to the "layer violation" (see my last mail to the e2e list).
About "crude discrimination" I partly agree. Don't you agree that having
identified a TCP flow guarantees that the coresponding application wants
full e2e reliability? As I said in an earlier mail, this approach is
limited. That's why I would much rather like to see a corresponding value
for the DS field that told me that the flow's application wants full "e2e
reliability", i.e. the transfer fails if the application layer data object
is corrupted when received by the destination application.

>traffic lifetimes at the link layer. Again, that breaks layering.

Again, see my last mail to the e2e list.

>all. That queuing impacts other users, no doubt...

Those packets remain queued for at most MSL/TTL minutes. No problem.

>replacement link, in order to get their own quick, reliable delivery

Unlikely, if you only have one access link (first/last hop) and that is a
wireless link.

///Reiner