Subject: Re: FW: PILC Minutes

From: Mikael Degermark <[email-masked]>
Date: Tue, 23 Nov 1999 03:26:29 +0100

A couple of comments:

>??: Do WAPs (Wireless Application Protocol)
>belong in the document?

I do not think so. WAP has very little to do with TCP/IP.
In fact WAP replaces TCP/IP with WAP specific protocols
over the radio link. I fail to see why we in the IETF should
do anything about WAP. WAP will die in a few years and it is
not TCP/IP. So why should we get involved?

>??: WAP doesn't use IP on one end.

>WAP doesn't specify Internet Protocols, but they are layering
>this on top of the Internet. WAP is THE hot topic for PEPs
>these days.

As WAP replaces TCP/IP with its own protocols over the wireless
link it is hard to see exactly how it can be said to be "on top"
of the Internet. It is also hard for me to see how WAP can be
called a proxy.

WAP is not TCP/IP. There is no reason for the IETF to worry about WAP.
If anything, we should point out how TCP/IP can run as efficiently
as the WAP protocols. One way to do that would be to examine the
*technical* reasons these people had for abandoning TCP/IP and showing
why those reasons are not valid (assuming, of course, that they aren't).

Mikael Degermark

---

From: "Dr. Carsten Bormann" <[email-masked]>
Date: Tue, 23 Nov 1999 09:51:31 +0100

> not TCP/IP. So why should we get involved?

I argued that way at the meeting, but after a few more hallway discussions,
I now agree that we should address WAP just for the one reason to make the

> why those reasons are not valid (assuming, of course, that they aren't).

Educated material on why WAP is not the best thing since sliced packets
(and, possibly, a few notes on where it actually does make a useful
contribution) would be a useful result from PILC.

Gruesse, Carsten

---

From: Owen Sullivan <[email-masked]>
Date: Tue, 23 Nov 1999 12:33:22 +0000

The WAP stack today does use UDP/IP over wireless bearers that support IP
to the handset, which is circuit switched data and packet data.  For wireless
bearers that have very restricted bandwidth, it doesn't use IP.  These non-IP
bearers are SMS (Short Messages Service), USSD (Unstructured Supplementary
Services Data) and Cell Broadcast.

For a discussion of WAP, including how it overlaps with IETF protocols, and
some of the reasoning behind decisions made in development of WAP protocols
please see  http://www.wapforum.org/what/WAP_white_pages.pdf

The protocols people involved in WAP are very interested in the PILC work
and have had presentations on the status of this work in each of the last
several meetings.

---

From: "John Border" <[email-masked]>
Date: Tue, 23 Nov 1999 09:27:19 -0500

On Nov 23,  9:51am, Dr. Carsten Bormann wrote:
> Subject: RE: FW: PILC Minutes
>-- End of excerpt from Dr. Carsten Bormann

The context of the WAP discussion re PILC is (or, maybe, "should be" is more
appropriate here) whether or not WAP should be included as a useful example of
a Performance Enhancing Proxy implementation in the PILC PEP draft.  The
purpose of the example would not be to point out the pros and cons of WAP
(although some of that might come out in describing it) but rather to use WAP
to illustrate PEP types, PEP mechanisms and/or reasons why PEPs get
implemented despite their some of their negative implications.  I don't
believe it is within the scope of the PILC working group to "do anything"
about WAP, although since I don't know much about WAP yet, I don't have a
problem with the discussion.  (The chairs can correct me if I am wrong on the
scope of the working group or the appropriateness of the discussion.)

John Border
Hughes Network Systems

---

From: Dr G Fairhurst <[email-masked]>
Date: Thu, 25 Nov 1999 14:21:24 +0100

http://www.ietf.org/internet-drafts/draft-ietf-pilc-error-02.txt

I have just read the above draft, and have the following comments
(if some of these have already been covered, please ignore them).

Section 2.2 Fast Retransmit and Fast Recovery [RFC2581]
========================================

End of para 1:

"Missing segments are detected by the receiver by segments arriving with
out-of-order sequence numbers."

I don't quite agree; I rather thought the receiver had little knowledge of what
was missing
or may be delayed, and usually (except with "SNACK") makes no decisions about
this.
I wonder if it would be wiser to say something along the lines of:

"The receiver does not normally detect missing segments, however it does
 send an acknowledgement for each received segment (irrespective of order).
 When the SACK option is used, for this feedback, the sender is able to imply
 loss of segments by the lack of an acknowledgement for the missing sequence
numbers."

Start of para 2:

" TCPs SHOULD immediately send an acknowledgement when data when is
   received out-of-order, sending the next expected sequence number
   with no delay, so that the sender can retransmit the required data
   and the receiver can resume delivery of data to the receiving
   application."

See above, I don't see it as a job of a TCP receiver to ***tell** the sender
what
to do.  The sender is merely informed and makes it own decision based on
the local information. The word "so", is perhaps a little strong? Should
it be "allowing" ?

Point 3:

     " 3. Often small socket buffers are recommended with high
      error-rate links in order to prevent the RTO from inflating."

As far as I know, this is a recommendation to people configuring stacks
and not usually an automatic process or one signalled by an
application.  Perhaps the documents should be clearer about who
does this tuning. Or am I wrong?

2.3 Selective Acknowledgements [RFC2018]
===============================

Para 2:

When we wrote ref [SF98] we included data for various error environments.

It became clear to us that:

(a) The SACK feedback provides congestion information by signalling explicit
leaving of packets from the network, and therefore available capacity over
the link with errors (using the usual conservative rules to grow cwnd).

(b) The SACK feedback provides implicit  loss indication following a previous
retransmission.  This implicit information may be extracted from viewing
the time of order of the exchange of retransmitted DATA segments
and the announcement of SACK information for each data segment.
I can explain more - but the key point for links with errors is that this
provides a safe way to detect loss of a retransmission, and to recover
it ***without*** reliance on the RTO - and therefore without invoking a
full slow-start event.

2.4 Delayed Duplicate Acknowledgements [MV97, VMPM99]
=========================================

Some people (including us) believe a great deal of performance improvement
is possible, simply by redesigning the link ARQ to match the needs of TCP.

Therefore I would suggest there are two approaches within the remit of the
group: (1) Modify TCP to allow link ARQ to operate, (2) Modify link ARQ
to mitigate the interactions with TCP.

2.5.1 Why we need Explicit Corruption Notification
====================================

Help? Does the C in  ECN mean Congestion or Corruption????
Is it wise to have two orthogonal issues with the same 3 letter abbreviation?

I also fear your recommendation at the end of the ECN  isn't perhaps careful
enough about the implications of different network topology?

Best wishes,

Gorry Fairhurst.