Subject: FW: PILC Minutes

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 22 Nov 1999 10:23:46 -0600

Please reply if you have questions, comments, or corrections. I plan to
forward these to the Secretariat in about a week.

Spencer 

> -----Original Message-----
> ---------------------
> Performance Implications of Link-layer Characteristics (PILC) Minutes
> November 10, 1999, Washington, DC
> 
> WG chairs:	Spencer Dawkins, Aaron Falk
> 
> Reported by Jim Griner (mailto:[email-masked]) and Tim Schweitzer
> (mailto:[email-masked])
> 
> Charts and documents are available from the PILC Web page at
> http://pilc.grc.nasa.gov.
> 
> Aaron Falk opened the meeting at 3:30pm and reviewed the agenda, which was
> accepted without comments.  He stated the LINK draft would not be
> discussed in detail, since the editor of the draft, Phil Karn, was not in
> attendance at this IETF.
> 
> Aaron then gave a status of the working group.  Most of the documents
> should be completed by the March IETF, except for the LINK draft which
> should be completed by July, and the "TCP Over Wireless" draft, which has
> been deferred until critical sections of SLOW, ERROR, and PEP have been
> reviewed.
> 
> Aaron also solicited for contributors to certain sections of the link
> draft. These sections are:
> 
> Quality of Service, Fairness vs Performance, Congestion signaling, Delay
> Characteristics, Buffering, flow & congestion control, Mobility,
> Multicasting (has already been started), Routing, Security. 
> 
> Interested contributors should contact Phil Karn directly, at
> mailto:[email-masked].
> 
Aaron's presentation is available at
http://pilc.grc.nasa.gov/pilc/meetings/dc/pilc-status.pdf.  

> ASYMMETRIC PATHS draft:
> 
> Venkata Padmanabhan presented the asymmetry draft. Venkata's presentation
> is available at http://pilc.grc.nasa.gov/pilc/meetings/dc/pilc-asym.pdf.
> 		
> Joe Touch:  By compressing ACKs you may be putting all your eggs in one
> basket, if ACKs are subsequently lost.
> 
> Venkata Padmanabhan:	ACK compression is more susceptible to ACK loss but
> it is not all or nothing.
> 		
> Van Jacobsen:	Link-level fragmentation is in the PPP spec. IPSEC with
> header compression is in RFC2507. Twice algorithm is not limited to single
> loss. It can be used multiple times, up to 16 packets.  
> 			
> Metacomment: Van indicated he had a problem with all PILC documents.  He
> thought they were supposed to be guidance documents to link and protocol
> designers.  He
> also thought we should be giving boundary criteria, and not just academic
> references.  Using header compression and preserving the entire ACK stream
> is more robust.
> 
> Aaron:  One PILC document is to give advice to link designers working on
> link technologies that haven't been deployed yet, while the other
> documents are to show and scope the problems with already-deployed
> "challenged" links and to propose solutions to these problems.
> 
> Van Jacobsen:	This might not be the best advice to designers, due to
> different motivations for the development of these academic solutions.
> 
> Van Jacobson: RFC 1144 header compression, in one-byte mode (as opposed to
> five-six-byte mode), handles 3000:1 asymmetry. Are we seeing connection
> paths that are more asymmetric than this? What's the point?
> 
> Aaron:	Points are well taken, and we will take this to the list.
> Authors should take note of Van's comments.
> 
> SLOW and ERROR drafts:
> 
> Spencer Dawkins gave the status of both the slow and error drafts.
> Spencer's presentation is available at
> http://pilc.grc.nasa.gov/pilc/meetings/dc/slow-error.pdf.
> 		
> Matt Mathis: Can we use negotiated timestamps at other times other than on
> SYNs?  This may require major RFC1323 changes, but the code changes are
> trivial.
> 
> Vern Paxon:	This is not in PILC's scope.  It can be submitted an
> individual ID, but not a PILC draft.
> 
> Matt Mathis:	Can we put text about these changes in the SLOW draft?
> 
> Van Jacobsen:	The SLOW draft should not contain anything about timestamps!
> 
> ??:	The SLOW draft implies that 296 is a good default MTU for dialup.
> 
> Spencer Dawkins: It needs to say that 296 is a COMMON MTU for dialup.
> 
> Gabriel Montenegro:	The link draft goes into an MTU discussion.  Maybe
> we should merge these MTU discussions into one draft.
> 
> Spencer Dawkins: We need to make sure that the recommendations are in the
> right place(s), and that they are consistent.
> 
> Aaron Falk:	The intent of the LINK document is to guide designers of new
> links for internet traffic.  It is probably appropriate for an MTU
> discussion in both drafts.
> 
> Van Jacobsen:  If there are interactions among parameters, they should be
> in the LINK draft.  Designers try to improve errors, but this in turn
> significantly increase delay in some links.  Don't look at parameters
> (error, delay, etc) individually.
> 
> Van Jacobsen:  In the ERROR draft, very early in the draft, there should
> be a paragraph on the TCP throughput equation. "Here's how to find out if
> you need to read further". Designers should do the equation, measure
> actual throughput, and see if errors really matter in each case.  If
> errors do not have a significant impact on throughput, then don't make any
> changes.
> 
> Spencer:  Concurred with Van's comments.
> 
> Aaron: The text in the docs touch on this, but should be expanded.
> 
> PEP draft - 
> 
> John Border gave a status update on the PEP draft. John's presentation is
> available at http://pilc.grc.nasa.gov/pilc/meetings/dc/pep-draft-1199.pdf.
> 
> 
> The latest PEP (01) draft did not make the cutoff for this IETF.  It will
> be released with minor changes after this IETF.  Another draft will be
> ready by March.
> 
> ??: Do WAPs (Wireless Application Protocol) belong in the document?
> 
> Markku Kojo:  As authors, this is also our question.!
>  
> ??: WAP doesn't use IP on one end.
> 
> Gabriel Montenegro:  WAP gateways are very large PEPs.  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.

---

From: Venkat Padmanabhan <[email-masked]>
Date: Mon, 22 Nov 1999 15:44:20 -0800

Just filling in the holes in a couple of places:

> thought they were supposed to be guidance documents to link 
> and protocol designers.  

When this point was raised, I clarified that the intent of the
current asym document (draft-ietf-pilc-asym-00.txt) was to survey
the range of asymmetry issues and solutions reported in the
literature, and not to recomment specific solutions. I believe both 
such a survey document and a more focussed "advice" document have 
their place, probably as separate RFCs (the former as Informational 
and the latter as BCP?).

> paths that are more asymmetric than this? What's the point?

Again, as I clarified when Van asked this question, our view of
asymmetry (at least as far as the I-D is concerned) is not limited to 
bandwidth asymmetry. There are instances of asymmetry in the MAC 
protocol (often due to the fundamental distributed setting of the network 
rather than poor engineering choices). In such situations, performance
would benefit a lot more from *infrequent* acks than from *smaller* 
(i.e., header compressed) acks, even if the bandwidth used by the ack 
stream is the same in both cases.

-Venkat

Venkat Padmanabhan
Microsoft Research
[email-masked]
http://www.research.microsoft.com/~padmanab

---

From: Venkat Padmanabhan <[email-masked]>
Date: Mon, 22 Nov 1999 20:24:15 -0800

> stream is the same in both cases.

One other point in this context is that the problems that arise 
in the presence of bidirectional traffic also necessitate solutions 
over and above header compression. I touched upon a subset of these
in my presentation. Note that while the problem arising from 
bidirectional traffic is not unique to asymmetric networks, 
asymmetry does tend to exacerbate the problem.

So, basically, I believe that while header compression is an 
invaluable tool in combating asymmetry, the problem is broad in
scope, hence there is a need for solutions that are broad in scope, too. 

-Venkat

Venkat Padmanabhan
Microsoft Research
[email-masked]

---

From: Zhimei Jiang <[email-masked]>
Date: Tue, 23 Nov 1999 09:16:24 -0500 (EST)

WAP defines a set of protocols that roughly covers transport layer 
all the way up to application layer. Although WTP (wireless transaction
protocol) and WDP (wireless datagram protocol) probably will not be 
used whenever TCP/IP is available, it is unclear to me whether small 
devices such as cell phones
will eventually have a TCP/IP stack. Other components of WAP, such as 
WML (wireless markup language), seem to have a good chance of surviving
as long as people continue to use cell phones for simple data access. 
An HTML to WML transcoding proxy would be one type of application level
PEP in this case. 

Zhimei

> Delivered-To: [email-masked]
> From: "Dr. Carsten Bormann" <[email-masked]>
> To: "Mikael Degermark" <[email-masked]>, "Spencer Dawkins" 
<[email-masked]>
> Cc: "'PILC Mailing List'" <[email-masked]>, "'Aaron Falk'" 
<[email-masked]>
> Subject: RE: FW: PILC Minutes
> Date: Tue, 23 Nov 1999 09:51:31 +0100
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> X-Priority: 3 (Normal)
> X-MSMail-Priority: Normal
> Importance: Normal
> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
> 
> > 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?
> 
> 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
> points you are making:
> 
> > 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
> 
> 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
> 

--

Zhimei Jiang
AT&T Labs -- Research
Room 4-128, 100 Schulz Drive
Red Bank, NJ 07701-7033
732-345-3156 (voice)
732-345-3039 (fax)

---

From: Mikael Degermark <[email-masked]>
Date: Tue, 23 Nov 1999 22:09:06 +0100

At 09:47 AM 99/11/23 -0500, Falk, Aaron wrote:
>> it is unclear to me whether small 
>> will eventually have a TCP/IP stack. 
>
>Why not?

I'll second that. Digital cell phones do some pretty intense signal
processing and
speech encoding/decoding. A TCP/IP stack is rather simple in comparison.
There might be reasons for not putting a TCP/IP stack in a cell phone, but
I don't 
believe that implementation size or complexity are such reasons. 

Moreover, when you want to hook your cell phone up to more than one wireless 
technology, there are some distinct advantages to using TCP/IP.

Mikael Degermark
>--aaron