IETF 45 Meeting Minutes: PILC

["Spencer Dawkins" <[e-mail]>]

Performance Implications of Link-layer Characteristics (PILC) 

Working group chairs: 	Spencer Dawkins (mailto:[e-mail])
						Aaron Falk
(mailto:[e-mail])

Reported by:		Anne Owen (mailto:[e-mail])

Home and mailing list contact information: http://pilc.grc.nasa.gov/pilc

MINUTES:

The first PILC workgroup meeting was held July 12, 1999 from 7:30 to 10:00
p.m. at IETF 45 in Oslo, Norway.

Aaron Falk, WG co-chair, kicked off with a short presentation on the PILC
charter (charter is http://www.ietf.org/html.charters/pilc-charter.html,
presentation is http://pilc.grc.nasa.gov/pilc/meetings/oslo/status.pdf),
reminding us that the PILC charter is to focus first on existing standards,
then looking at new technologies if existing standards can't provide
acceptable performance.

PILC was responsible for delivering five I-Ds by IETF 45. Four of the five
have been produced. The fifth, on asymmetric connections, has been delayed.
Aaron and Spencer view the remaining PILC milestones as ambitious but
(barely) achievable, and Aaron asked the WG assemblage to consider an
interim meeting (before IETF 46 in early November). Comments should be sent
to the PILC list.

Spencer Dawkins presented feedback that has been received on the PILC SLOW
I-D (http://www.ietf.org/internet-drafts/draft-ietf-pilc-slow-00.txt,
presentation at http://pilc.grc.nasa.gov/pilc/meetings/oslo/slow.pdf). This
draft has a simple outline - don't send bits you don't have to send; use
compression so you don't have to send them. Recent comments are focusing on
strategies for sending "the right bits" first (class-based queuing, etc.)

Comment: Some discussion about whether TCP timestamps should be recommended
over challenged links or not. The draft will be edited to include this
discussion.

Comment: This draft should reflect applicable recommendations from ISSLL,
especially the ISSLOW work.

Comment: This draft should distinguish between what's done for low-bandwidth
and what's done for small window sizes.

Spencer Dawkins presented feedback that has been received on the PILC ERROR
I-D (http://www.ietf.org/internet-drafts/draft-ietf-pilc-error-00.txt,
presentation at http://pilc.grc.nasa.gov/pilc/meetings/oslo/error.pdf). This
draft is limited in scope, because there's not a way to tell the difference
between congestion loss and corruption loss without using intermediate
nodes, which are discussed in the PEP draft.

Phil Karn presented the LINK draft
(http://people.qualcomm.com/karn/pilc.txt). The purpose of this draft is to
"reconnect the disconnect" between subnet designers and the IP community.
There are several sections of the document which still need text (and, in
some cases, authors to contribute text): "QoS, fairness versus performance,
and congestion signaling", "delay characteristics", and "buffering, flow and
congestion control". Phil also identified "green field" areas that need to
be written: mobility, broadcast and discovery, routing, and security.
Interested co-authors are solicited - contact Phil at
mailto:[e-mail] to volunteer.

Phil pointed out that most often, link layers do too much (repeating
functionality that is also provided at higher layers), but that there are a
couple of areas where link layers do too little (multicast, QoS).

Comments: Asymmetry isn't the only problem for cable modems - there's a
one-ACK-per-polling cycle restriction, so that it's very difficult to send
ACKs "upstream". This reduces the benefit of ACK compression.

Comment: There are a lot of GET requests, in addition to ACKs, in upstream
traffic. It's possible to swamp ACKs on cable modems when you are retrieving
all the resources on an HTML page.

Comment: We need link-level support for IP packet length, because we can't
use the IP header length information if the header is compressed.

Comment: We need large MTUs for digital signatures.

Comment: Links like RLP and ATM are going to do fragmentation, but this
shouldn't be visible to IP protocol implementations.

Markku Kojo presented the recently-submitted PEP I-D
(http://www.ietf.org/internet-drafts/draft-ietf-pilc-pep-00.txt,
presentation at http://pilc.grc.nasa.gov/pilc/meetings/oslo/pep.pdf). Markku
believes that most of the work remaining on this draft is in the PEP
Environment examples (filling in the blanks).

Comment: Lots of people who should contribute to the PEP work don't know
that PILC exists.

Comment: The draft should include the effect of multi-homing environments on
PEPs.

Comment: The draft should include QoS transparency implications.

Comment: The draft should reflect (co-chair's editorial comment - as far as
is reasonable) terminology from the glossary in the WREC taxonomy draft
(http://www.ietf.org/internet-drafts/draft-ietf-wrec-taxonomy-01.txt) and
the (soon-to-be-released) WREC known problems draft.

Mikael Degermark presented an overview of current work in header compression
CRTP
(http://search.ietf.org/internet-drafts/draft-degermark-crtp-cellular-00.txt
) and ROCCO
(http://search.ietf.org/internet-drafts/draft-jonsson-robust-hc-00.txt), as
a heads-up on work that is being done in AVT (presentation at
http://pilc.grc.nasa.gov/pilc/meetings/oslo/header-comp.pdf). (SLOW should
point to this work, but comments on this work should be directed to the
authors themselves).

Yongguang Zhang presented a proposal for Multi-layer IPSEC. The approach
describes implementation changes that could allow IPSEC protocols to be used
with PEPs. This material has not yet been reviewed by the IPSEC working
group and may be submitted to tf-esp. A white paper can be found at
http://www.wins.hrl.com/people/ygz/ml-ipsec/. Yongguang has indicated that
he will be submitting this as an Internet draft.

GENERAL DISCUSSION:

Comment: HTTP is actually often (and counter-intuitively) large requests
with small responses (lots of GET header fields, 304 GET responses with no
entity bodies), etc.

Comment: HTTP servers don't do persistent connections because they don't
want to stay open six seconds. Even HTTP/1.1 servers are configured to turn
off persistent connections. The motivation is to save own CPU at the cost of
network performance. This is the same reason servers don't want to compress
on the fly.

Comment: A lot of the problems that HTTP persistent connections were
intended to solve can also be solved by TCP control block sharing, and we
could be doing this today.

Comment: The win for HTTP persistent connections is pulling down all the
embedded resources in a page, and then closing the connection immediately.