Subject: PEP Implications re Qos Transparency and Multi-Homing

From: John Border <[email-masked]>
Date: Fri, 29 Sep 2000 10:53:58 -0400

At the Pittsburgh PILC meeting, I brought up the idea of deleting the PEP
implications re QoS Transparency and Multi-Homing sections because the authors
do not know what to put into these sections (and they did not seem that
important to us).  Objections were raised to this plan, i.e. some people still
think these sections are important.  But, we are still stuck with not knowing
exactly what to write into these sections.  So, we are looking for volunteers
to write some text.  Barring that, some feedback explaining what the working
group thinks are the issues related to PEPs versus QoS Transparency and PEPs
versus Multi-Homing might provide us enough information to write the text
ourselves...

John

---

From: John Border <[email-masked]>
Date: Fri, 29 Sep 2000 10:47:36 -0400

The attached text below is the PEP implications re end-to-end failure
diagnostics text we have added to the PILC PEP draft.  Since this section was
previously blank, we decided to send this text to get early feedback rather
than wait for the next version of the document to be released.  (I realize
that feedback might be affected by not having the entire document for context
but...)

John

4.1.4 End-to-end Failure Diagnostics

   Another aspect of the end-to-end argument is the ability to support
   end-to-end failure diagnostics when problems are encountered.  If a
   network problem occurs which breaks a connection, the end points of
   the connection will detect the failure via timeouts.  However, the
   existence of a PEP in between the two end points could delay
   (sometimes significantly) the detection of the failure by one or
   both of the end points.  (Of course, some PEPs are intentionally
   designed to hide these types of failures as described in Section
   3.4.)  The implications of delayed detection of a failed connection
   depend on the applications being used.  Possibilities range from no
   impact at all (or just minor annoyance to the end user) all the way
   up to impacting mission critical business functions by delaying
   switchovers to alternate communications paths.
   
   In addition, tools used to debug connection failures may be
   affected by the use of a PEP.  For example, PING (described in
   [RFC792] and [RFC2151]) is often used to test for connectivity.
   But, because PING is based on ICMP instead of TCP (i.e. it is
   implemented using ICMP Echo and Replay commands at the network
   layer), it is possible that the configuration of the network might
   route PING traffic around the PEP.  Thus, PING could indicate that
   an end-to-end path exists between two hosts when it does not
   actually exist for TCP traffic.  Even when the PING traffic does go
   through the PEP, the diagnostics indications provided by the PING
   traffic are altered.  For example, if the PING traffic goes
   transparently through the PEP, PING does not provide any indication
   that the PEP exists and since the PING traffic is not being
   subjected to the same processing as TCP traffic, it may not
   necessarily provide an accurate indication of the network delay
   being experienced by TCP traffic.  On the other hand, if the PEP
   terminates the PING and responds to it on behalf of the end host,
   then the PING provides information only on the connectivity to the
   PEP.  Traceroute (also described in [RFC2151]) is similarly
   affected by the presence of the PEP.