Re: [hops] Middlebox on your device

"Honda, Michio" <michio@netapp.com> Tue, 24 March 2015 09:02 UTC

Return-Path: <michio@netapp.com>
X-Original-To: hops@ietfa.amsl.com
Delivered-To: hops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 516B91B2D92 for <hops@ietfa.amsl.com>; Tue, 24 Mar 2015 02:02:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VlspbjKy06mp for <hops@ietfa.amsl.com>; Tue, 24 Mar 2015 02:02:02 -0700 (PDT)
Received: from mx142.netapp.com (mx142.netapp.com [216.240.21.19]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5D9F1B2D8E for <hops@ietf.org>; Tue, 24 Mar 2015 02:02:02 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.11,457,1422950400"; d="scan'208";a="30696255"
Received: from hioexcmbx06-prd.hq.netapp.com ([10.122.105.39]) by mx142-out.netapp.com with ESMTP; 24 Mar 2015 01:57:02 -0700
Received: from HIOEXCMBX08-PRD.hq.netapp.com (10.122.105.41) by hioexcmbx06-prd.hq.netapp.com (10.122.105.39) with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 24 Mar 2015 01:57:02 -0700
Received: from HIOEXCMBX08-PRD.hq.netapp.com ([::1]) by hioexcmbx08-prd.hq.netapp.com ([fe80::c55f:997c:5201:2a2c%21]) with mapi id 15.00.0995.031; Tue, 24 Mar 2015 01:57:02 -0700
From: "Honda, Michio" <michio@netapp.com>
To: Szilveszter Nadas <Szilveszter.Nadas@ericsson.com>
Thread-Topic: [hops] Middlebox on your device
Thread-Index: AdBlu73as0T2GeDBSbGOaK8PQbtMigAj2xWA
Date: Tue, 24 Mar 2015 08:57:01 +0000
Message-ID: <574B9864-4A05-48AC-920C-331C392E60B7@netapp.com>
References: <EA4C43BE752A194597B002779DF69BAE23CC03D3@ESESSMB303.ericsson.se>
In-Reply-To: <EA4C43BE752A194597B002779DF69BAE23CC03D3@ESESSMB303.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.122.56.79]
Content-Type: text/plain; charset="utf-8"
Content-ID: <F2885282BA113040AEA858CDCDED7342@hq.netapp.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/hops/wjiDub9L7lXDJgcdfuhu8Dw1av4>
Cc: "hops@ietf.org" <hops@ietf.org>
Subject: Re: [hops] Middlebox on your device
X-BeenThere: hops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Measuring deployability of new transport protocols <hops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hops>, <mailto:hops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hops/>
List-Post: <mailto:hops@ietf.org>
List-Help: <mailto:hops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hops>, <mailto:hops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Mar 2015 09:02:04 -0000

In addition to those software you should be a bit careful about NICs.
For example, TSO copies options in the original big segment into all the split segments, and LRO only aggregates packets that do not accompany options (except for Timestamps)
Our paper (http://conferences.sigcomm.org/imc/2011/docs/p181.pdf) shows this behavior on some NICs.

It should be noted that whether packets are affected by NICs or not also depends on how we generate and receive packets.
For example, if we generate and receive raw packets using BPF or netmap, those packets will not be affected.
However, I have no idea if we do so using raw sockets and AF_PACKET, because they let certain level of packet processing, such as checksum calculation to occur in the network stack.

Cheers,
- Michio

> On Mar 24, 2015, at 00:02, Szilveszter Nadas <Szilveszter.Nadas@ericsson.com> wrote:
> 
> Hi,
>  
> What if the “middlebox” blocking some transport feature/field is on the end-user device, e.g. a firewall software? Maybe saying the obvious here, just wanted to mention that sometimes it might not be the ISP the one to blame. Maybe it is not even important who to blame. Probably/hopefully firewall software is easier to update though, but it can have quite an effect on the measurement results.
>  
> (slightly related to this thread: http://www.ietf.org/mail-archive/web/spud/current/msg00028.html) 
>  
> Cheers,
> Sz.
> _______________________________________________
> hops mailing list
> hops@ietf.org
> https://www.ietf.org/mailman/listinfo/hops