first-packet loss without state, case ARP [Re: [RAM] The mapping problem: rendezvous points?]

Pekka Savola <pekkas@netcore.fi> Thu, 10 May 2007 05:32 UTC

Return-path: <ram-bounces@iab.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm1Gc-00006n-8j; Thu, 10 May 2007 01:32:42 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm1Gb-00006a-1Z for ram@iab.org; Thu, 10 May 2007 01:32:41 -0400
Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hm1Ga-0003qW-GF for ram@iab.org; Thu, 10 May 2007 01:32:41 -0400
Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id l4A5WYDP017741; Thu, 10 May 2007 08:32:34 +0300
Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id l4A5WYgk017738; Thu, 10 May 2007 08:32:34 +0300
Date: Thu, 10 May 2007 08:32:34 +0300
From: Pekka Savola <pekkas@netcore.fi>
To: David Conrad <drc@virtualized.org>
Subject: first-packet loss without state, case ARP [Re: [RAM] The mapping problem: rendezvous points?]
In-Reply-To: <85F8BDA4-1EAA-4043-8CDB-112CEF29B2BC@virtualized.org>
Message-ID: <Pine.LNX.4.64.0705100828530.16314@netcore.fi>
References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <9C228355-9425-4C66-A9A7-47498490E3B1@virtualized.org> <271CF87FD652F34DBF877CB0CB5D16FC054EA59D@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <86588E66-ACED-4DD2-B286-3DA5B2518B1A@virtualized.org> <4641750A.9010906@cisco.com> <283D52E5-AD3A-40FA-B81C-27DD950176CA@virtualized.org> <3DF89B6B-0CC4-4C60-9519-80CF5FECCE9B@nokia.com> <F2F9AE97-7599-42BB-A542-A4B33AC3FD18@virtualized.org> <F3A8A33D-614D-4E6F-9741-61FFBB42E40C@nokia.com> <85F8BDA4-1EAA-4043-8CDB-112CEF29B2BC@virtualized.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-Virus-Scanned: ClamAV 0.90.2/3224/Wed May 9 18:25:29 2007 on otso.netcore.fi
X-Virus-Status: Clean
X-Spam-Status: No, score=-3.3 required=5.0 tests=ALL_TRUSTED, AWL, BAYES_00 autolearn=ham version=3.1.8
X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on otso.netcore.fi
X-Spam-Score: -2.8 (--)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: ram@iab.org
X-BeenThere: ram@iab.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Routing and Addressing Mailing List <ram.iab.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ram>
List-Post: <mailto:ram@iab.org>
List-Help: <mailto:ram-request@iab.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=subscribe>
Errors-To: ram-bounces@iab.org

On Wed, 9 May 2007, David Conrad wrote:
>> First off, all the ARP implementations I know of queue the packet during 
>> the loopkup, i.e., no loss.
>
> That's what I thought, but folks have been saying that routers don't queue 
> anymore.

AFAIK, almost any router an operator would be willing to call a router 
deployed today start ARP (or ND) resolution process when a packet 
arrives that requires resolution.  The packet that initiated ARP/ND 
request is discarded, as are subsequent packets until the resolution 
is complete.

I understand queueing the triggering packets could be a DoS vector for 
networks where the target IP is down.

So, first-hit loss is not completely unheard-of in todays networks.

However, ARP/ND related loss only occurs per destination (and with 
usually long timers -- up to hours), not on (source, destination) 
basis.  That's why you very rarely see ARP-based packet loss even when 
starting communication with a new host.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
RAM mailing list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram