LAST-minute PILC IETF 51 minutes review

"Dawkins, Spencer" <Spencer.DAWKINS@fnc.fujitsu.com> Thu, 06 September 2001 13:57 UTC

Message-ID: <C197C4E892DE244C895D5465422ECFF80ED730@rchemx06>
From: "Dawkins, Spencer" <Spencer.DAWKINS@fnc.fujitsu.com>
To: "'pilc@grc.nasa.gov'" <pilc@grc.nasa.gov>
Subject: LAST-minute PILC IETF 51 minutes review
Date: Thu, 06 Sep 2001 08:57:04 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-pilc@grc.nasa.gov
Precedence: bulk
Status: RO
Content-Length: 3774
Lines: 83

Dear all,

Sorry for the last-minute notice - but if you have comments before the Friday, September 7 deadline, please send them along!

Spencer Dawkins

p.s. We're still putting documents into a couple of the URLs listed...

-------------------------

Meeting Date: Tuesday, August 6, 2001 
Meeting Time: 1415 - 1515 (one hour) 
Meeting Location: 
  Hilton London Metropole 
  225 Edgware Road 
  London, United Kingdom W2 1JU

Working group chairs:	Spencer Dawkins (mailto:spencer.dawkins@fnc.fujitsu.com) and 
				Aaron Falk (mailto:a.falk@ieee.org)

Notes taken by:		Spencer Dawkins (mailto:spencer.dawkins@fnc.fujitsu.com) 
				Gab Montenegro (mailto:gab@sun.com)
				Rod Ragland (mailto:rragland@hns.com) 

Agenda 
====== 

0. Agenda bashing 

Agenda slides are available at http://pilc.grc.nasa.gov/meetings/ietf51/pilc-status.pdf.

1. Working group status

PEP (RFC 3135, INFO), SLOW (RFC 3150, BCP 48), and ERROR (RFC 3155, BCP 50) have been approved as RFCs (ERROR was still in the RFC editor queue, but has been published since the London meeting). We're close on LINK (BCP), ARQ (INFO), and ASYM (INFO). We have more work to do on 2.5G3G (BCP), but should be able to finish this document before the next IETF. PILC may not meet at IETF 52 (Salt Lake City).

2. Discussion of docs in progress

- ARQ:

Gorry presented draft-ietf-pilc-link-arq-issues-02.txt 
 
ARQ was "hummed" for working group last call, after minor editorial updates (version 03).
 
Slides are available at http://pilc.grc.nasa.gov/meetings/ietf51/pilc-arq-02-pres-51.pdf.


- ASYM:

Gorry presented draft-ietf-pilc-asym-05.txt.

We discussed making this document Experimental track, but decided that the mitigations aren't described in enough detail to allow experimentation.

Comment: this document needs to be less prescriptive, if it's going to be Informational.

ASYM was "hummed" for working group last call, after minor editorial updates (version 06).

Slides are available at http://pilc.grc.nasa.gov/meetings/ietf51/pilc-asym-05-pres-51.pdf.


- 2.5G3G:
	
Hiroshi presented draft-ietf-pilc-2.5g3g-03.txt.

This document didn't get a lot of discussion until it was last-called in the working group, but we did get last-call comments, involving bandwidth-delay product, connection splitting, applications section (which has been removed), etc. The chairs' opinion is that we're a couple of revisions away from an RFC.

"Careful TCP splitting" is not being recommended in a BCP-targeted document.

If one-percent error rates are possible with 3GPP, this needs to be pointed out in the document, probably in Section 2, because error rates this high will definitely affect performance.

Reiner Ludwig put in a plea for a longer initial RTO value, because the current 3-second maximum is too close to the 1.5 seconds it takes for a maximum-length packet to clear an 8000-bps link. This is a tradeoff, because a longer timer value is the obvious right answer for slow links, but penalizes fast links.

Slides are available at http://pilc.grc.nasa.gov/meetings/ietf51/pilc-ietf51-presen.pdf.

- LINK:

Phil presented draft-ietf-pilc-link-design-06.txt.

This document is essentially complete, except for discussions we're having about the Security Considerations section.

The basic question is what we say about subnetwork-level security.

We have agreement that there's no substitute for end-to-end security, and that subnetwork infrastructure needs to be protected. Our remaining issue is what we say about encryption of user data at the subnetwork level, and our concern is whether recommending bulk encryption will make IPSEC more or less likely to be deployed. We agreed not to DIScourage subnetwork encryption.

This discussion needs to be completed on the mailing list (in September!).