Subject: pilc minutes from IETF-50

From: [email-masked]
Date: Mon, 9 Apr 2001 10:19:55 -0400

PILC WG Meeting
Thu Mar 22, 2001
================
Reported by: Spencer Dawkins/Aaron Falk/Mark Allman
Slides available at http://pilc.grc.nasa.gov.

Working Group Status: 
---------------------
ERROR and PEP through WG last call and have been submitted
to the AD.  The IDs will be put on the IESG plate soon.

SLOW has passed WG last call and will be forwarded to the IESG after
this meeting.

LINK is on track for last call (in next few weeks).

Documents still pending: 2.5g3g, ASYM and ARQ.  The goal is to
conduct WG last calls for all these documents before the next IETF
meeting. 

The PILC charter calls for possible re-chartering to address some of
the issues raised by the group.  However, to dat no issues have been
raised and therefore PILC will likely go dormant after the current
set of documents are completed.

SLOW Status - Markku Kojo
-------------------------
WG last call complete.

A few minor language tweaks are being added:
  * MTU size selection text clarified.
  * Slow start text clarified.

Document now explicitly recommends Limited Transmit.

LINK Status -- Phil Karn
------------------------
Lots of typos and nits fixed.

QoS architecture description added (written by Dan Grossman).

ARQ section added, all known issues resolved.

Phil recommends going ahead with WG last call after this meeting.

Issue: should subnetwork encryption be added?  Yes, if free, but not
a substitute for higher level encryption to protect user data
end-to-end. 

Issue: some questions raised on list regarding peformance formulae,
need experts to resolve issue, editor not the right person.

  Reiner Ludwig: on performance formula - holds for connections with
  high degree of multiplexing, not as applicable for links with few
  connections, like those outlined in SLOW.

  Dan Grossman: on security - we should recommend that link designers
  bring security of wireless links up to meet expectations users have
  of point-to-point links.

  Markku Kojo: on flow seperation language - concerned about
  implicitly recommends that it's the LINK layer which is doing the
  flow seperation, should be IP layer. Link designers may implement
  in hardware preventing addition of e.g. new DS codepoint.

    Reiner Ludwig: doc should only point out that this can be
    helpful. 

    Gorry Fairhurst: some text on this in ARQ draft.

  Spencer: on formulas - please review forumlas and continue to
  identify boundry conditions.

  Sally: state that forumulas are approximate rules of thumb, not
  explicit, there are many assumptions on TCP type, traffic
  characteristics.

    Reiner Ludwig: they are just not valid for low mulitplexing
    connections, need to add language stating thus.

ARQ Status -- Gorry Fairhurst
-----------------------------
This draft was originally slated to be rolled into LINK.  However
the current feeling is that content is rich enough to warrent a
seperate document.

See slides for overview of the presentation.

Several outstanding issues:

  * sharing & low persistance
  * bumps & bursts
  * classification of application needs
  * multiple links along a path, and duration of high persisitance
  * shared channels -- cost of retransmission on a shared channel

Comment from Andre Wutoff (sp?) GPRS-2.5G: have two link layers both
capable of retransmission, one of IP packets and one for
fragments. Would like to see discussion of performance tradeoffs for
persistancy at the two different layers.

Dan: don't think perfect persistancy is real.

  Gorry: perfect refers to retransmission up to N2 times a
  timeout. High is much higher than RTT. Low is on the order of an
  RTT. 

  Bill Simpson: use "very high" or "ultra high" rather than
  "perfect".

  Dan: discuss retransmitting fragments vs. whole packets.

ASYM Status -- Gorry Fairhurst
------------------------------

The significant changes from the last rev of ASYM are: 

  * more examples and recommendations have been added
  * a bit about the relationship of this document to PEP was added
  * the various techniques have been better organized

The authors are soliciting additional examples of asymmetric
networks.  In addition, the authors wish any sort of input the
comunity has to offer (taxonomy right?  recommendations OK?  etc.) 

Dan Grossman suggested that DSL is a major example.

ludwig: what are the "problem ratios"?  misunderstanding about the
definition of k in the id, i think

2.5G3G Status -- Hiroshi Inamura
--------------------------------
Background info presented and can be found in the I-D.

Issues:

  Gorry Fairhurst: MTU recommendation - does MTU realy have more
  loss? 
    
    Hiroshi: MTU doesn't affect loss rate.

  Gorry Fairhurst: name server reference in ID as part of Ricochet -
  does not refer to DNS and may confuse readers.

  ???: is this profile just for next generation WAP or general
  wireless? How would PMTU work in general case?

    Hiroshi: by using example of 2.5G/3G you know the MTU.

  Gorry Fairhurst: timestamps -- why recommend timestamps? Is this
  for PAWS? Is there a really high variation of RTT? Do we need
  timestamps? 

    Hiroshi: recommendation came from need for window scaling.

    Gorry Fairhurst: only need window scaling (and, hence PAWS) for
    high bandwidth links. Not needed for this application. Should
    verify need.

    Mark Allman: timestamps should not be recommended. Need to see
    justification if you want to recommend it. PAWS doesn't apply
    here. As for RTTM, conservative RTT estimate given in RFC 2988
    make it unnecesssary.

    Carston Borman: ROHC wants to enable timestamps with header
    compression which should help if you need to use it.

---

From: Dr G Fairhurst <[email-masked]>
Date: Tue, 24 Apr 2001 13:51:30 +0100

Some people have asked me on progress with clarification of the 
ARQ text included in the current link ID.

Following the IETF meeting in Minneapolis, the following co-authors
suggest a replacement of the ARQ text in the link draft. This is based 
on the text in the last issued link ID.  We hope this new
text clarifies the debate on ARQ persistency at IETF-49 and IETF-50.
We also intend it to be consistent with the remainder of the link draft
and 
with the related ARQ draft (draft-ietf-pilc-link-arq-issues-XX.txt). 

The replacement text below has not changed since 12th April 2001.

Gorry Fairhurst
Lloyd Wood
Reiner Ludwig

In the coming weeks, a revision of the ARQ draft,
based on feedback received - and any further comments - will 
be issued to give more detailed discussions of the ARQ issues
(draft-ietf-pilc-link-arq-issues-XX.txt).

--------

TCP vs Link Layer Retransmission

Error recovery generally involves the retransmission of lost or
corrupted data when explicitly or implicitly requested by the
receiver. It can also involve the generation and transmission of
redundant information that lets the receiver regenerate or correct
some amount of lost or corrupted data without needing explicit
retransmission of that amount.

The retransmission approach, widely known as "ARQ" (Automatic ReQuest
repeat) for largely historical reasons, is found in many computer
networking protocols.

The redundant information approach, using error control coding (of
which Forward Error Correction, or FEC, is a well-known
example) takes place in the data-link layer, very close to the
physical layer. Many link layers use a combination of both
coding and ARQ retransmissions to improve performance.

Depending on the layer where it is implemented, error control can
operate on an end-to-end basis or over a shorter span such as a
single link.  TCP is the most important example of an end-to-end
protocol that uses an ARQ strategy.

A large number of link layer protocols use ARQ, most
often some flavor of HDLC [ISO3309]. Examples include the X.25 link
layer, the AX.25 protocol used in amateur packet radio, 802.11
wireless LANs, and the reliable link layer specified in IEEE 802.2.

As explained in the introduction, only end-to-end error recovery can
ensure a reliable service to the application. But some subnetworks
(e.g., many wireless links) also require link layer error recovery as
a performance enhancement.  For example, many cellular links have
small physical frame sizes (< 100 bytes) and relatively high frame
loss rates. Relying entirely on end-to-end error recovery clearly
yields a performance degradation, as retransmissions across the end-to-end
path take much longer to be received than when link-local
retransmissions are used. Thus, link-layer error recovery can often 
increase end-to-end performance. As a result, link-layer and end-to-end 
recovery often co-exist; this can lead to the possibility of inefficient
interactions between the two layers of ARQ protocols.

This inter-layer "competition" might lead to the following wasteful
situation. When the link layer retransmits a packet, the link latency
momentarily increases. Since TCP bases its retransmission timeout on
prior measurements of end-to-end latency, including that of the link
in question, this sudden increase in latency may trigger an
unnecessary retransmission by TCP of a packet that the link layer is
still retransmitting.  Such spurious end-to-end retransmissions
generate unnecessary load and reduce end-to-end throughput. One may
even have multiple copies of the same packet in the same link queue
at the same time. In general, one could say the competing error
recovery is caused by an inner control loop (link layer error
recovery) reacting to the same signal as an outer control loop (end-
to-end error recovery) without any coordination between both loops.
Note that this is an efficiency issue, TCP continues to provide
reliable end-to-end delivery over such links.

This raises the question of how persistent a link layer sender should be in
performing retransmission. We define as link layer (LL) ARQ persistency the
maximum time that a particular link will spend trying to transfer a
packet before it can be discarded. This deliberately simplified
definition says
nothing about maximum number of retransmissions, retransmission
strategies, queue sizes, queuing disciplines, transmission delays, or
the like. The reason we use the term LL ARQ persistency instead of a
term such as 'maximum link layer packet holding time' is that the
definition closely relates to link layer error recovery. For example,
on links that implement straightforward error recovery strategies,
LL ARQ persistency will often correspond to a maximum number of
retransmissions permitted per link layer frame [ARQ-DRAFT].

For link layers that do not or cannot differentiate between flows
(e.g., due to network layer encryption), the LL ARQ persistency
should be small.  This avoids any harmful effects or performance 
degradation resulting from indiscriminate high persistence.
A detailed discussion of these issues is provided in [ARQ-DRAFT].

However, when a link layer is able to identify separate flows [ARQ-DRAFT]
and isolate the effects of ARQ on different flows sharing the same link
(or all
flows observe common patterns of loss (e.g. an outage).  The link
ARQ persistency for a flow should be high for a flow using reliable unicast
transport protocols (e.g., TCP) and must be low for all other flows. 
Setting the link ARQ persistency larger than the largest link
outage, would allow TCP to rapidly restore transmission without
the need to wait for a retransmission time out, generally improving
TCP performance in the face of transient outages.  However, excessively
high persistence may be disadvantageous (a practical upper limit of
30-60 seconds may be desirable). Implementation of such 
schemes remains a research issue. (See also Section "Recovery from 
Subnetwork Outages"). 

Recovery from Subnetwork Outages

Some types of subnetworks, particularly mobile radio, are subject to
frequent but temporary outages. For example, an active cellular data user
may drive or walk into an area (such as a tunnel) that is out of
range of any base station. No packets will be successfully delivered
until the user returns to an area with coverage.

The Internet protocols currently provide no standard way for a
subnetwork to explicitly notify an upper layer protocol (e.g., TCP)
that it is experiencing an outage, as distinguished from severe
congestion.

Under these circumstances TCP will, after each
unsuccessful retransmission, wait even longer before trying again;
this is its "exponential backoff" algorithm. And since there is also
currently no way for a subnetwork to explicitly notify TCP when it is
again operational, TCP will not discover this until its next
retransmission attempt. If TCP has backed off, this may take some
time.  This can lead to extremely poor TCP performance over such
subnetworks.

It is therefore highly desirable that a subnetwork subject to outages
not silently discard packets during an outage. Ideally, it should
define an interface to the next higher layer (i.e., IP) that allows
it to refuse packets during an outage, and to automatically ask IP
for new packets when it is again able to deliver them. If it cannot
do this, then the subnetwork should hold onto at least some of the
packets it accepts during an outage and attempt to deliver them when
the subnetwork comes back up.

Note that it is *not* necessary to avoid any and all packet drops
during an outage. The purpose of holding onto a packet during an
outage, either in the subnetwork or at the IP layer, is so that its
eventual delivery will implicitly notify TCP that the subnetwork is
again operational.

This is to enhance performance, not to ensure
reliability -- a task that as discussed earlier can only be done
properly on an end-to-end basis.

Only a single packet per TCP connection need be held in this way to
generate a TCP ack to cause the TCP sender to recover from the 
additional losses once the flow resumes.

Because it would be a layering violation (and possibly a performance hit)
for IP or a subnetwork to
look at the TCP headers of the packets it carries (which would in any
event be impossible if IPSEC encryption is in use), it would be
reasonable for the IP or subnetwork layers to choose, as a design
parameter, some small number of packets that it will retain during an
outage.