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
- [Tsvwg] Rethinking Karn's algorithm Reiner Ludwig
- Re: [Tsvwg] Rethinking Karn's algorithm Armando L. Caro Jr.
- Re: [Tsvwg] Rethinking Karn's algorithm Reiner Ludwig
- Re: [Tsvwg] Rethinking Karn's algorithm Armando L. Caro Jr.
- Re: [Tsvwg] Rethinking Karn's algorithm Mark Allman
- Re: [Tsvwg] Rethinking Karn's algorithm Reiner Ludwig
- Re: [Tsvwg] Rethinking Karn's algorithm Mark Allman
- Re: [Tsvwg] Rethinking Karn's algorithm Reiner Ludwig
- Re: [Tsvwg] Rethinking Karn's algorithm Mark Allman
- Re: [Tsvwg] Rethinking Karn's algorithm Reiner Ludwig
- Re: [Tsvwg] Rethinking Karn's algorithm Mark Allman
- Re: [Tsvwg] Rethinking Karn's algorithm Reiner Ludwig
- Re: [Tsvwg] Rethinking Karn's algorithm Spencer Dawkins
- Re: [Tsvwg] Rethinking Karn's algorithm Reiner Ludwig
- Re: [Tsvwg] Rethinking Karn's algorithm Spencer Dawkins
- Re: [Tsvwg] Rethinking Karn's algorithm Mark Allman
- Re: [Tsvwg] Rethinking Karn's algorithm Phil Karn
- [Tsvwg] Re: Rethinking Karn's algorithm Phil Karn
- Re: [Tsvwg] Re: Rethinking Karn's algorithm Reiner Ludwig
- Re: [Tsvwg] Re: Rethinking Karn's algorithm Spencer Dawkins
- Re: [Tsvwg] Re: Rethinking Karn's algorithm Mark Allman
- Re: [Tsvwg] Re: Rethinking Karn's algorithm Reiner Ludwig
- Re: [Tsvwg] Re: Rethinking Karn's algorithm Caitlin Bestler
- Re: [Tsvwg] Re: Rethinking Karn's algorithm Qiaobing Xie
- Re: [Tsvwg] Re: Rethinking Karn's algorithm Randall Stewart
- Re: [Tsvwg] Re: Rethinking Karn's algorithm Spencer Dawkins
- Re: [Tsvwg] Re: Rethinking Karn's algorithm Phil Karn