Re: [Spud] Middlebox to middlebox declarations in SPUD?
"Joe Hildebrand (jhildebr)" <jhildebr@cisco.com> Mon, 09 March 2015 21:30 UTC
Return-Path: <jhildebr@cisco.com>
X-Original-To: spud@ietfa.amsl.com
Delivered-To: spud@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 553971A8BB6 for <spud@ietfa.amsl.com>; Mon, 9 Mar 2015 14:30:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 TYlX3llZzw9C for <spud@ietfa.amsl.com>; Mon, 9 Mar 2015 14:30:48 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF31F1AC3D1 for <spud@ietf.org>; Mon, 9 Mar 2015 14:30:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=864; q=dns/txt; s=iport; t=1425936648; x=1427146248; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=ZTQ0Psr03m0FXD/p1XDrj3/b4yMgYB6FLGvI/cL4ph0=; b=mDgAIxDpMLuB+YcKgvVIhaBYxgozj+mRm8EjVApJrmY4rpriZle026Q2 uqema1TQT2dHvBz11+WgQ/QQNU9/lJcikxBvPB7DQqZqn/GRnnE9jeync htC/gLOUp8BOpUMWX62DNrkZcixg2poSxpPKj7ijajGCt7yW+RYVqKW+c o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BqGwA1EP5U/5xdJa1cgwaBLASDBrlog0iIJh6BD00BAQEBAQF8hBACBCMRVwEIGgImAgQwFRIEARKIL6NTm2YBAQEBAQEBAwEBAQEBAQEBAQEBF4EhiXaEeYJkL4EWAQSQD4lTk3Qjg25vgUR/AQEB
X-IronPort-AV: E=Sophos;i="5.11,370,1422921600"; d="scan'208";a="402163528"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 09 Mar 2015 21:30:47 +0000
Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t29LUlHB024684 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Mar 2015 21:30:47 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.156]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Mon, 9 Mar 2015 16:30:46 -0500
From: "Joe Hildebrand (jhildebr)" <jhildebr@cisco.com>
To: Szilveszter Nadas <Szilveszter.Nadas@ericsson.com>, "spud@ietf.org" <spud@ietf.org>
Thread-Topic: [Spud] Middlebox to middlebox declarations in SPUD?
Thread-Index: AQHQWrBORnHsapANS0muK8cPWUbQnQ==
Date: Mon, 09 Mar 2015 21:30:46 +0000
Message-ID: <CCF1B48C-9375-495C-B175-174F10F04024@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/15.8.0.150225
x-originating-ip: [10.24.213.230]
Content-Type: text/plain; charset="utf-8"
Content-ID: <F2654A960100D544A54817B5D4CAAED4@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/spud/wZIkF8VOeAENx8KVWTaRXtEBT7M>
Subject: Re: [Spud] Middlebox to middlebox declarations in SPUD?
X-BeenThere: spud@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Session Protocol Underneath Datagrams <spud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spud>, <mailto:spud-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/spud/>
List-Post: <mailto:spud@ietf.org>
List-Help: <mailto:spud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spud>, <mailto:spud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Mar 2015 21:30:49 -0000
On 3/6/15, 8:59 AM, "Szilveszter Nadas" <Szilveszter.Nadas@ericsson.com> wrote: > >Philosophically, we could look at the user/OS as a middlebox in this scenario. In that case some it is easier to find middlebox to middlebox use cases. If this philosophy is applied it might also be easier to solve these questions. That feels right to me. Similarly, as I've been prototyping, I was worried about what to do with packets I missed, since the OS isn't queueing for me. Once I started thinking about those packets as just lost on a different segment of the path, I stopped worrying about them. -- Joe Hildebrand
- [Spud] Middlebox to middlebox declarations in SPU… Szilveszter Nadas
- Re: [Spud] Middlebox to middlebox declarations in… Joe Hildebrand (jhildebr)