PILC Minutes for IETF-49

[[e-mail]]

Performance Implications of Link Characteristics (PILC) IETF-49 Summary
Minutes 

Reported by: Jim Griner ([e-mail])

Aaron opened with agenda bashing on Friday 12/15/00 at 9:00AM

Agenda
  Agenda Bashing & WG Status (5)
  Lower layer guidelines for ROHC - Bormann (10)
  TCP over Wireless - Inamura (5)
  draft-ietf-pilc-slow-05.txt - Dawkins (5)
  draft-ietf-pilc-pep-05.txt - Border (10)
  draft-ietf-pilc-link-design-05.txt - Karn (10)
  draft-ietf-pilc-link-arq-issues-00.txt - Karn (for Fairhurst, Wood) (10)
    Alternate perspective from Reiner Ludwig (10)

No comments on agenda


Aaron gave a working group status:
- TCP on errored links has been submitted to IESG for consideration as BCP
- Should we take slow, pep and link to last call?
- Need to resolve the future of asym.
- Need to draft text for TCP over wireless.

Aaron gave the status of the asym draft:
- At the Washington IETF some concerns were raised that asymmetries shown in
the draft were not severe enough to merit working group attention.  This
lead the work being halted on the draft.
- Prior to this IETF, the -01 draft was cleaned up and submitted as -02.
This version was a clean-up of the previous draft.  A new draft will be
submitted after this IETF.
- Will be asking on the mailing list if we should continue with this effort,
after the next draft.



Carsten Borman gave a status of using ROHC for TCP:

- Need header compression on IP-Wireless however wireless is lossy
- 2508 causes loss propagation on long RTT links

There are currently two main work items within the ROHC working group:
- ROHC for IP/UDP/RTP
- ROHC for TCP

In the RTP area there three documents: 
- lower-layer guidelines
- requirements
- main RTP ROHC deliverable

Why should the ROHC TCP be develop separately?
- The ROHC requirements may be less stringent, due to link layer
retransmissions.
- RFC 2507 is not enough.

ROHC is soliciting more input on TCP header compressions. There are
currently two drafts: taroc and epic

requirements:
- Should not disable TCP mechanisms.
- Must not generate damaged headers that pass TCP checksum.
- Must deal with current and future TCPs.
- Want it to work well for short-lived TCP connections.

Call for help:
- Design must be influenced by link layers.
- Needs documented information on underlying link layers.
	- current version 
	- for the next 5 years
- Link layer designers need ROHC TCP information
- Develop a lower layer guideline document.
- Help with overall ROHC TCP scheme.

http://www.dmn.tzi.org/ietf/rohc


Hiroshi Inamura gave a status on the proposed TCP over Wireless draft:

Why do we need this document?
- To add uniformity on TCP implementations in installed base of mobile
handsets.
- There is also little information on where WAP is going

WAP forum is completing TCP specification for handsets based on IETF/PILC
recommendations. There has been a lot of effort in this area and we need to
document it in a BCP document.

Audience comments:
Aaron:  This is effort similar in form to how the TCP over satellite work
started, documenting effects of satellite links (latency, errors, etc.) We
need to publish to the list what this document is going to look like, so you
can get more input on the document focus areas.

Spencer: You might want to show how items within this document are similar
to items within other PILC documents.

?: Want more information on how imode works
Hiroshi: Imode was already presented in Adelaide plenary session, but will
provide this information.

?: Thought imode used transactional TCP
Hiroshi: no it uses ....

Spencer gave the status of the slow draft:
- -05 has some editorial changes, and thinks it is ready for last call

Aaron: We have been working on this draft 1 1/2 years and thinks it is ready
for last call.

A straw poll was conducted...  Of the people who have read the draft, they
indicated it is ready for last call. No one in attendance who had read the
draft objected to it going to last call.

?: Thinks it might need a security section 
Spencer: That is a good idea.  We need to think about it.



John Border gave the status of the PEP draft:
- There were some changes from -03 to -04 based on comments from the
Pittsburgh IETF meeting related to document scope
- Reworked the implications sections to make it clearer

The PEP draft went for last call in mid October, but didn't receive many
comments. The comments were incorporated and were released in the -05 draft.


Aaron:  Will send it up for last call based on straw poll of the people who
had read the draft.



Phil Karn gave the status of the link draft.

- -04 is essentially done except for the QoS and ARQ debates
- Can probably include ARQ text
- All remaining sections have been filled in
- made a couple of changes in QoS and Packet Reordering

New sections since -03
	- fairness vs performance
	- multicasting
	- routing (IP vs subnet)
	- delay characteristics
	- security

ARQ delima:
- persistent ARQ is good when it speeds up TCP recovery after a long outage
- persistent ARQ is bad when it retransmits packets which have already been
retransmitted end to end or needlessly

- Possibly use high persistence ARQ for TCP,ICMP, UDP based transactions
- Use low persistence for RTP/UDP
- can be done heuristically but better done with... 

Audience comments:
Dan: sent in a large section for QoS section, but it wasn't adequately
incorporated.  Wants clarification on what should be in the QoS section.

Phil: likes the comment, and thinks we need more clarification 

?: Lets leave it out for now, since we don't know what we want to do

Phil:  Thinks we need to include some text, that way there is some
information for future use

Aaron: We should not be making recommendations on diffserv issues

Phil: Does anyone have a problem with current text?

Dan: We need a little bit of a wrapper around the current text.

Kathy:  Didn't see anything controversial about the text.

Dan:  RFC 2474 obsoletes the TOS field as we use to know it, and there is a
new semantic of these bits for edge to edge use

Kathy:  One can use the TOS bits in a wide variety of ways, and the draft
says how the field use to be used but it doesn't say how they are used now.
Just refer to RFC 2474 and RFC 2780 for how they are used now.

Dan:  The bits are used on hop by hop rather than end-to-end.  We shouldn't
be overemphasizing those bits.  We shouldn't be focusing on this area, but
rather more of the overall picture.

Aaron:  We should be telling link designers how to work with the diffserv
and intserv information that is available.

Kathy:  You just want to refer to the other RFCs on these issues.

Dan: will provide some more text

Gabe:  ECN area should be revised in link draft, since the ECN draft is now
going for RFC.



Phil Karn gave a presentation on the ARQ issues for IP traffic
	
- We don't aim to categorize ARQ definitely, just to make people aware of
what it can do to IP traffic.

---- See presentation for all the details ----


Reiner Ludwig gave a presentation on 'Can wireless preserve the end-to-end
argument'

- wireless link layers should be flow adaptive

How to implement:  
	- use link layer sniffing or a clean layered design

	Argument:  everything should be done at the end-points, but this has
been shown to not be the case

	link layer sniffing is a layer violation, but so is ROHC

- Flow-adaptive breaks with IPSEC

Link layer ARQ persistency for reliable flows
- assume flow-adaptive link layer
- assume link layer ARQ is possible
- link layer ARQ persistency for TCP?

Simply setting the MTU to small enough values and use TCP-SACK does not
work.

Want to recommend to link layer designers that link layer ARQ should try for
up to 64 seconds to transmit a TCP packet
- this is not saying unbounded queues
- this is not saying to use hop-by-hop reliability instead of end-to-end
reliability

High delays due to link layer ARQ are very rare, usually they are less than
1 sec, and mainly occur during link outages This is the most spectrum end
energy efficient method.  Discarding a packet that has made it 90% across
the link is not efficient. Provides robustness against link outages

There are concerns about spurious retransmissions, inflated RTO, head of
line blocking, but these are all easily solved.

Flow-adaptive Link layer and high persistent link layer ARQ for TCP
eliminates non congestion TCP losses and eliminates the need for a proxy No
need for robustness in TCP/IP header compression scheme, and VJ header
compression will work just fine.

Phil Karn:  the 64 second time could be eliminated if there was an
expiration on the packet

Ludwig: yes, we should use TTL in ms.

Carsten Borman: Likes the idea of determining flow differences, in reference
to determining how robust the header compression should be.

Ludwig:  With TTL in ms and an idea of what the application wants, we could
do a lot.

Carsten Borman: We can't just look at the links, since some links may not be
persistent

Ludwig:  doesn't buy this argument.  

Karn:  Disagrees with slow draft that timestamps should be avoided

Aaron: The slow draft is targeted towards legacy links

Karn:  Thinks there was disagreement between slow and link

?:  Can you just look at TOS field to determine flow information 
Ludwig:  With IPSEC the DS field is the only that is not encrypted

Dan: Are you sure you want to do front dropping
Ludwig:  This is the fastest way to signal TCP

Markku: Doesn't agree with elimination of head of line blocking problem
Ludwig:  Cannot allow a flow that has trouble to be taking up all the queue
space.  We should take this off-line

Carsten Borman: --Put up a TCP throughput equation, to show there is a RTO
component--
Ludwig: Doesn't have a good answer, since this is a research topic (for
developing this equation) since it was developed for a high degree of
multiplexing and not for a low degree of multiplexing that we have here. We
shouldn't be so scared of spurious timeouts.  You have to pay for your poor
link at some point.

Aaron: Need to think about this more, before we put it in a document.  Take
this to the list for more discussion.
Ludwig: Thinks we already have consensus on these issues
Aaron:  Before we make this recommendation we should talk about it on the
list
Ludwig:  We are not going to make specific recommendation on how to separate
flows.  But if you can't do this, then don't follow the additional
recommendations.
Spencer:  Might want to list alternatives to help the discussion on the
list.

The meeting was adjourned at 10:50.

Jim Griner