Subject: Some comments to the draft-ietf-pilc-error-00.txt

From: Morten Schläger <[email-masked]>
Date: Mon, 21 Jun 1999 14:13:17 +0200

1.) I understand that the draft focuses on TCP issues. However, on 
    the other hand, I think  some recommendation for UDP flows should/could 
    also be given. In case of UDP over error prone links a semi reliable
    link protocol should be used. Further the sending rate and the socket
    buffer of the wireless/mobile end-system should be chosen according to 
    the link speed and maybe the quality (e.g. to give the link layer protocol 
    some time to respond to errors without building up queues of new packets.)

2.) On page 9 last paragraph before chapter 3 the drafts says: "However the 
    requirement that the base station be able to examine the TCP headers 
    flying through it raises issues with the respect to IPSEC-encrypted packets."
    
    Considering the direction from the mobile/wireless host to base station:
    In case a reliable or semi reliable link layer protocol is used a negative 
    confirmation (in case that the link layer protocol could not deliver 
    a packet) could be used as a loss notification for the sending TCP instance. 
    The advantage of this approach (concerning IPSEC) is that the base station needs not to
    read TCP packet headers. Furthermore only the protocol stack on the end
    system must be modified.

3.) Interlayer communication within the mobile/wireless end system (e.g. 
    number of packets in the device queue)  could be used for example to adapt the 
    sending rate of the transport protocol to the capacity of the wireless link
    especially in case of errors or to signal that a packet is still not transmitted
    in order to prevent unnecessary TCP retransmissions.

Best Regards,

Morten

-- 
------------------------------------------------------------------------
Morten Schläger                              Tel.: ++49 (030) 314-23834
Technical University Berlin                   Fax.: ++49 (030) 314-23818
Telecommunication Networks Group (TKN)            [email-masked]
Sekr. FT 5-2/Einsteinufer 25    
10587 Berlin, Germany

---

From: Reiner Ludwig <[email-masked]>
Date: Mon, 21 Jun 1999 10:41:43 -0700

At 05:13 AM 6/21/99 , Morten Schläger wrote:
>    link protocol should be used. 

I basically agree, but how persistent should the retransmissions be, i.e.,
how much extra delay (due to retransmissions) per IP packet can we allow?
We don't have that information at the link layer but could try to make a
"smart" guess. Which?

>    Further the sending rate and the socket

Don't agree. We should not confuse application-layer/transport-layer
communication (through socket buffers) with that of queue management -
active or passive - at the link layer. I know that socket buffer tuning is
a "hack" to improve performance but we should not recommend it. Instead,
the size of interface buffers should be chosen according to the interfaces
speed (e.g. by assuming a worst-case RTT of 500 ms) as a kind of passive
queue management. Even better: some kind of active queue management which
is already recommended in draft-ietf-pilc-error-00.txt.

>    a packet) could be used as a loss notification for the sending TCP
instance. 

This requires that you can identify that "sending TCP instance". The port
numbers will be encrypted and if there is no flow label, you're stuck.

>    in order to prevent unnecessary TCP retransmissions.

Sounds like massive protocol-layer violation which, I believe, is not
necessary.

///Reiner

---

From: Mikael Degermark <[email-masked]>
Date: Mon, 21 Jun 1999 21:34:10 +0200

>    link protocol should be used.

That is a lousy idea for low-bandwidth links where applications need 
low delay, for example voice. The best way to utilize such links is to 
use codecs that tolerate damaged packets. Having a semi-reliable link layer
will not use the spectrum efficiently and will introduce delay.

I would not put such a general statement as the one you propose into 
any PILC document. 

>    some time to respond to errors without building up queues of new
packets.)

It is not necessarily the economically best solution to design the system
in the way you propose. For applications involving humans, such as voice
and video, in error prone and low bandwidth environments, it is generally
better (from an economical point of view) to have codecs that can tolerate
damaged payloads. 

Mikael Degermark

http://www.cdt.luth.se/~micke

---

From: Morten Schläger <[email-masked]>
Date: Tue, 22 Jun 1999 16:08:02 +0200

> I would not put such a general statement as the one you propose into

I agree that the statement above is far to general to be included in the draft.
But I'm not that sure that semi-reliable protocols are unsuitable at all. Depending
from the link speed an additional retransmission might only cost a couple of milli-
seconds which, I believe,  is tolerable in an IP-based network, especially when playout buffers are used.

> >    ...rest deleted....

Thanks for the comments,

Morten

---

From: Morten Schläger <[email-masked]>
Date: Tue, 22 Jun 1999 16:08:01 +0200

> We don't have that information at the link layer but could try to make a

Yes, this is indeed a problem. If you try to guess it's a hard (but interesting) task. 
On the other hand, depending from the link speed a additional try might only cost
a few milliseconds. If this helps to deliver a packet (without an error), then I
think it is worth doing. 
At the very moment this is only an idea and of course some results should be provided.
So I'm (and was) not asking to put this general remark in the draft.

> is already recommended in draft-ietf-pilc-error-00.txt.

Yes, the interface buffers should be chosen according to the interface speed 
independent of the higher layer protocols. But what I was trying address is the 
problem that a UDP based application can fill the whole interface buffer if it only sends fast enough. I know that the interaction between TCP and UDP is a general problem but 
it might be even worse for TCP connections if they have to content with UDP 
over a (slow) error prone link. 
Anyway the socket buffer is not the right place to solve this problem (since in 
case of UDP it only specifies the maximum size of a datagram). 
One possible solution are adaptive applications which reduce their sending rate when write-calls return s.th. like insufficient memory (e.g. ENOBUFS).

> numbers will be encrypted and if there is no flow label, you're stuck.

This is again true. However, since I only spoke about the direction from the wireless
end-system to the base station and since the code of the end system has to be modified in anyway it should be possible to provide s.th. like a local flow label which allows an 
association between link-layer packets and their acknowledgments to TCP instances.
 
> >   ...rest deleted...

Thanks for the comments,

Morten

---

From: Reiner Ludwig <[email-masked]>
Date: Tue, 22 Jun 1999 08:58:05 -0700

At 07:08 AM 6/22/99 , Morten Schläger wrote:
> [...] However, since I only spoke about the direction from the wireless
>end-system to the base station and since the code of the end system has to
be 
>modified in anyway [...] 

Don't agree. TCP works just fine over _reliable_ wireless links without the
need to change any TCP/IP code:

Bhagwat, P., Bhattacharya, P., Krishna, A., Tripathi, S. K., Using channel
state
dependent packet scheduling to improve TCP throughput over wireless LANs,
Wireless Networks, Vol. 3, No. 1, pp. 91-102, 1997.
Eckhardt, D. A., Steenkiste, P., Improving Wireless LAN Performance via
Adaptive
Local Error Control, In Proceedings of IEEE ICNP 98.
Ludwig, R., Rathonyi, B., Konrad, A., Oden, K., Joseph, A., Multi-Layer
Tracing
of TCP over a Reliable Wireless Link, In Proceedings of ACM SIGMETRICS 99.
Ludwig, R., A Case for Flow-Adaptive Wireless Links, Technical Report
UCB//CSD-99-1053, University of California at Berkeley, May 1999.
Meyer, M., TCP Performance over GPRS, To Appear In Proceedings of IEEE WCNC
99.

///Reiner

---

From: "Bora Akyol" <[email-masked]>
Date: Tue, 22 Jun 1999 13:01:51 -0700

Reiner

Let us not open the open the subject of whether TCP should be fixed or
whether the wireless links should be made reliable instead. Here
are my reasons for saying this:

1) Reliability is an end-to-end functionality which TCP does, why duplicate
it at the link layer.

2) In some wireless links in order to achieve high reliability you either
need:
	** A lot of FEC
	** or an ARQ procedure which induces delay.
3) For most wireless links, the error rates encountered on the link
are highly variable with time and location (resolution of half-wavelength).
Due to this fact, most of the time FEC is considered as a waste of resource.

In the end (IMHO), it is much cleaner to improve the upper layer protocols.

Bora Akyol

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Reiner Ludwig
Sent: Tuesday, June 22, 1999 8:58 AM
To: Morten Schläger
Cc: Reiner Ludwig; [email-masked]
Subject: Re: Some comments to the draft-ietf-pilc-error-00.txt

be

Bhagwat, P., Bhattacharya, P., Krishna, A., Tripathi, S. K., Using channel
state dependent packet scheduling to improve TCP throughput over wireless
LANs, Wireless Networks, Vol. 3, No. 1, pp. 91-102, 1997.
Eckhardt, D. A., Steenkiste, P., Improving Wireless LAN Performance via
Adaptive Local Error Control, In Proceedings of IEEE ICNP 98.
Ludwig, R., Rathonyi, B., Konrad, A., Oden, K., Joseph, A., Multi-Layer
Tracing of TCP over a Reliable Wireless Link, In Proceedings of ACM
SIGMETRICS 99.
Ludwig, R., A Case for Flow-Adaptive Wireless Links, Technical Report
UCB//CSD-99-1053, University of California at Berkeley, May 1999.
Meyer, M., TCP Performance over GPRS, To Appear In Proceedings of IEEE WCNC
99.

///Reiner

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 22 Jun 1999 22:37:37 +0100 (BST)

> 1) Reliability is an end-to-end functionality which TCP does, why duplicate

That bizarre catch-all assertion seems to open the subject you don't
want to open quite nicely...

Why ensure (not duplicate) reliability at the link layer? Because we
don't have explicit congestion notification, and we want thoughput.
Yes, TCP _works_ over badly errored unreliable links. But it doesn't
_perform well_ (partly thanks to assuming errors are congestion), and
a large part of pilc's initial output is devoted to explaining that.

The end-to-end principle explains why you can't go _without_
end-to-end checking for data integrity, and how intermediate data
integrity spot checks are no substitute for an end-to-end check, and
can be redundant and removed if you _do_ have end-to-end checking.

However, redundancy of checking for integrity is rather different from
engineered reliability of media/links for throughput and
_performance_.

You'd be correct to complain about per-hop ACKing of data as per
X.25; that's redundant with end-to-end checking. Reliable
works-right-first-time-because they're-adequately-coded links are not.
(and, gee, UDP/RTP performance benefits from good coding too.)

> 	** or an ARQ procedure which induces delay.

FEC is a good choice; FEC is a process, not a check on a process.

Local ARQ duplicates TCP checksum functionality and is against
end-to-end, as I point out above. TCP already does the checking; the
added ARQ delay messes up TCP's RTT estimates, in any case.

FEC and ARQ are orthogonal; TCP effectively duplicates ARQ
functionality and makes ARQ redundant, but it doesn't duplicate FEC
functionality. It can't. TCP can check the integrity of what is
delivered by the transmission process, but it can't improve on it.

> Due to this fact, most of the time FEC is considered as a waste of resource.

Specific examples, please. This certainly isn't the case with wireless
satellite links I'm familiar with.

> In the end (IMHO), it is much cleaner to improve the upper layer protocols.

Funny, I wasn't aware that _that_ was pilc's charter.  What is this,
some kind of troll?

L.

And if it isn't, a read of the end-to-end paper might be a good idea:
http://people.qualcomm.com/karn/library.html

> Meyer, M., TCP Performance over GPRS, To Appear In Proceedings of IEEE WCNC

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

---

From: Cannara <[email-masked]>
Date: Tue, 22 Jun 1999 14:51:27 -0700

To agree with both, consider that TCP relies on good links, since it currently
can't distinguish error losses from congestion losses -- a very serious
problem for TCP on the links being discussed here.  There are ways to improve
this at the transport, but I've yet to see serious TCP work on anything but
congestion issues, which misses much of what these links will challenge a
transport with.  

I think the classically successful engineering approach should be to do
whatever optimizes both components of the system, including their
interactions.

Alex

---

From: Eric Travis <[email-masked]>
Date: Tue, 22 Jun 1999 18:22:12 -0400 (EDT)

On Tue, 22 Jun 1999, Lloyd Wood wrote:

<stuff snipped until it finally degenerated to...>

> Funny, I wasn't aware that _that_ was pilc's charter.  What is this,

Perhaps you should recheck the charter before reporting any future troll
sightings... 

Clearly stated in the next to last paragraph of the pilc charter
(http://www.ietf.org/html.charters/pilc-charter.html):

 The working group will also serve as a forum for discussing possible
 modifications to IETF protocols to improve performance in environments
 with problematic link characteristics - however, not to the detriment 
 of performance and stability in the general Internet, nor to undermine
 existing security models. 

Even though the WG isn't chartered to draft protocol modifications for
"improving the upper layer protocols", it seems that *discussing* the
topic is certainly within the bounds of the official charter.

Regards,

Eric

---

From: Mikael Degermark <[email-masked]>
Date: Wed, 23 Jun 1999 10:48:14 +0200

Hi Morten,

I was reacting to the SHOULD you used in 1). SHOULD is a pretty 
strong recommendation. If the link has a large roundd-trip time (several
tens of milliseconds), it would be a bad idea to retransmit. 
And there are such links out there! So please, if
semi-reliability is included in the draft, qualify the statement!