Subject: Re: pilc minutes for IETF 48

From: Nitin H Vaidya <[email-masked]>
Date: Thu, 21 Sep 2000 09:30:46 -0500 (CDT)

>> > If you have a reliable link layer protocol (ARQ) _and_ you tune the error
  >> > recovery persistency of that protocol to a high value like 64 seconds
  >> > (TCP's max. RTO), you pretty much eliminate losses but trade them for delay.
  >> >
  >> > ***However***, you have to ensure that the link layer does this _only_ for
  >> > the reliable flows such as the TCP-based flows.

Some folks seem to be arguing that we can solve the errored-link
problem at the link layer by doing ARQ-for-ever & differentiating
between TCP and UDP.

I have seen some of the papers which show that link layer
retransmission can solve the problem in some environments - I
agree that "limited" ARQ can help reliable flows ...

... however, I am not convinced that retransmitting for 64 seconds
or some such large interval of time is always terribly useful.

Even if we grant (for the sake of the argument) that this
might always improve throughput of a TCP transfer, is that
necessarily better from a user's perspective ?

May be, for some TCP connections, response time is also relevant.
What if we are looking at a web user who gets impatient and
starts clicking "reload" every 10 seconds? Or, gives up
and decides to look up some other web page ? The work done
in buffering and retransmitting-to-eternity may be wasted/redundant
in this case.

The point is that there is something of a continuum between
"reliable" and "non-reliable" flows, and a greater granularity of
information is necessary to do the right thing at the link layer.
If such information is not available, why not use
a generic feedback mechanism to inform the transport layer (e.g., ICMP),
and let each transport layer (or application) do what it deems best.
(I am not suggesting that we discard ARQ - the feedback can be used
in conjunction with limited ARQ, or when limited ARQ fails).

Also, it may not be possible to reduce non-congestion losses
to a negligible level in all wireless environments. Even if we
somehow manage this in the last-hop wireless scenario, in
multi-hop mobile environment, this may not be practical - here, we
may have frequent losses due to route changes (carrying the
"fully reliable ARQ" argument to this case would require the
network layer to be "fully" reliable too!).

Best regards.

- nitin

---

From: "Injong Rhee" <[email-masked]>
Date: Thu, 21 Sep 2000 12:32:29 -0700

I agree with Nitin. I want to go even further by leaving all arq decisions
to the transport (supported by TCP) or sometimes to the application
(supported by UDP). I think just some hints like why packets are lost (even
in some cases, corrupted packets delivered are useful with indication that
it is corrupted) would help applications a lot. My point is that
applications have to have some flexibility as to what kind of reliability
they want. What if applications do not want any arq at all? I can see why
some perf. improvement can be achieved by doing link-level arq when
applications want it. However, is this benefit good enough to trade the
flxibility at the application?

Just some thoughts from an application designer.
Injong Rhee
---

Injong Rhee
NCSU
www.csc.ncsu.edu/faculty/rhee

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Nitin H Vaidya
Sent: Thursday, September 21, 2000 7:31 AM
To: [email-masked]
Subject: Re: pilc minutes for IETF 48

Best regards.

- nitin

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 21 Sep 2000 18:04:57 +0100 (BST)

> problem at the link layer by doing ARQ-for-ever & differentiating

I'd _really_ like to know how you can differentiate between TCP and
UDP given e.g. use of IPSec. (In a diffserv framework you cannot
expect TCP and UDP to be marked separately, particularly if you're
downstream. And, again, there's IPSec.)

Watching flow behaviour can tell you which flows are controlled and
congestion-sensitive or uncontrolled and not, so that you can treat
them differently and ensure fairness, but it won't tell you whether a
flow is intended as reliable or unreliable by its application, or
whether it's (gack) TCP or UDP.

L.

layeringabstractionlayeringabstractionlayeringabstraction.

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

---

From: Reiner Ludwig <[email-masked]>
Date: Thu, 21 Sep 2000 23:04:24 +0200

At 18:04 21.09.00 +0100, Lloyd Wood wrote:
>UDP given e.g. use of IPSec.

And also this had been discussed before. But, so what ...

Yes, Lloyd, you're right with IPsec there is really no way you can 
distinguish TCP flows from the rest since the IP proto-ID field gets 
overwritten by IPsec.

This is why I really wish we still had the old TOS-byte semantics which 
would have been ideal for such "application to link layer" signalling. It 
could have been used by the source to say: "hey, this flow is marked as 
being a reliable flow (TCP, Reliable Multicast, NFS, ...)".

On the other hand, with IPsec also any ICMP-Kick-TCP scheme is screwed 
because the port numbers are also encrypted. Or do we want to tell the 
receiving Web server to forward the ICMP signal to all 1000 of it's TCP 
connections?
(one might get around this if the entire packet is returned with the ICMP 
message *and* the source is able to decrypt it again).

///Reiner

---

From: "Injong Rhee" <[email-masked]>
Date: Thu, 21 Sep 2000 19:46:33 -0700

Then with IP-sec, how should we solve the differentiation problem? It seems
there is no solution. Then should we apply arq at all? I guess the best
option is no-arq.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Reiner Ludwig
Sent: Thursday, September 21, 2000 2:04 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: pilc minutes for IETF 48

///Reiner

---

From: Reiner Ludwig <[email-masked]>
Date: Fri, 22 Sep 2000 14:53:27 +0200

At 19:46 21.09.00 -0700, Injong Rhee wrote:

>there is no solution.

I agree. This is a difficult problem that remains to be solved. Maybe we 
need to get some e2e semantics back into the DS field .... ?

>Then should we apply arq at all? I guess the best
>option is no-arq.

I agree. No link layer ARQ at all or at least with a very low error 
recovery persistency (<< 1 second).

///Reiner