Subject: RE: PILC ASYM document

From: Nitin H Vaidya <[email-masked]>
Date: Mon, 6 Mar 2000 14:40:13 -0600 (CST)

>> From: Venkat Padmanabhan <[email-masked]>
  ...
  >> in the same category -- link layer algorithms that utilize TCP-specific
  >> knowledge without necessarily modifying TCP itself. In that sense,
  >> I believe these are bang on target for PILC; basically, designers
  >> of such links may need to spinkle some TCP-specific magic dust to
  >> have their links perform well with unmodified end-to-end TCP.
  >> (N.B.: The draft surveys a whole range of alternatives, some of which
  >> do involve mods to the e2e TCP.) 

Have we exhausted alternatives that do NOT require the link
layer to understand TCP?

IMHO it is a great idea to have layers communicate information
to each other, but it does not seem a good idea to require the
link layer to understand the transport protocol.

I hope we can agree on this.

For instance, it seems reasonable to design a link layer with,
say, 2 service classes (such as, never retransmit, versus
retransmit X times) -- then each packet sent to the link layer
could be tagged with the appropriate service class to be used
for that packet

The above alternative would be preferable over requiring the
link layer to take different actions depending on whether
a packet belongs to, say, TCP or UDP.

In my opinion, before this group endorses alternatives that
require link layer to understand transport protocol, a case
needs to be made to show that more reasonable/palatable
alternatives do not exist.

Cheerio.

- nitin

---

From: Cannara <[email-masked]>
Date: Tue, 07 Mar 2000 09:13:58 -0800

Nitin,

If the link handles reasonable MTUs and only understands that TCP performs
poorly when packets disappear due to errors, rather than router congestion,
then that should be enough, since that's a TCP and network-layer failing to
manage paths and inform ends well.

Alex