Re: [Tsvwg] Rethinking Karn's algorithm

Reiner Ludwig <Reiner.Ludwig@eed.ericsson.se> Mon, 31 March 2003 14:19 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07027 for <tsvwg-archive@odin.ietf.org>; Mon, 31 Mar 2003 09:19:41 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VEgwv07292 for tsvwg-archive@odin.ietf.org; Mon, 31 Mar 2003 09:42:58 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VEgfO07253; Mon, 31 Mar 2003 09:42:41 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VEY5O06114 for <tsvwg@optimus.ietf.org>; Mon, 31 Mar 2003 09:34:05 -0500
Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06832 for <tsvwg@ietf.org>; Mon, 31 Mar 2003 09:10:17 -0500 (EST)
Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2VECfUE002765; Mon, 31 Mar 2003 16:12:41 +0200 (MEST)
Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2AG6HZX9; Mon, 31 Mar 2003 16:12:41 +0200
Received: from res0010384da36.eed.ericsson.se (dhcp5-197.eed.ericsson.se [164.48.135.197]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id QAA26750; Mon, 31 Mar 2003 16:12:40 +0200 (MET DST)
Message-Id: <5.2.0.9.0.20030331160237.02607f48@mailhost.eed.ericsson.se>
X-Sender: eedrel@mailhost.eed.ericsson.se
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Mon, 31 Mar 2003 16:12:42 +0200
To: Spencer Dawkins <spencer_dawkins@yahoo.com>
From: Reiner Ludwig <Reiner.Ludwig@eed.ericsson.se>
Subject: Re: [Tsvwg] Rethinking Karn's algorithm
Cc: Reiner Ludwig <Reiner.Ludwig@eed.ericsson.se>, mallman@grc.nasa.gov, tsvwg@ietf.org, Phil Karn <karn@qualcomm.com>
In-Reply-To: <20030331135536.74415.qmail@web10908.mail.yahoo.com>
References: <5.2.0.9.0.20030331152101.025e7e00@mailhost.eed.ericsson.se>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Sender: tsvwg-admin@ietf.org
Errors-To: tsvwg-admin@ietf.org
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>

At 15:55 31.03.2003, Spencer Dawkins wrote:
>I believe that post-IETF 56, what's actually on the table in
>TRIGTRAN is end-systems resending one "last packet" at link-up
>time, not routers sending triggers.

Fine. But don't we have exactly that already in section 8.2 ("Recovery from 
Subnetwork Outages") of draft-ietf-pilc-link-design-13.txt which is a 
soon-to-be-BCP-RFC:

    "[...]
    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. When packets are discarded, IP should
    be notified so that the appropriate ICMP messages can be sent.

    Note that it is *not* necessary to completely avoid dropping packets
    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. [...]"

And this works for both, hosts and routers.

///Reiner 

_______________________________________________
tsvwg mailing list
tsvwg@ietf.org
https://www1.ietf.org/mailman/listinfo/tsvwg