Re: [IPsec] comments on esp-null-heuristics-01

Tero Kivinen <kivinen@iki.fi> Wed, 25 November 2009 14:00 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37A9828C24B for <ipsec@core3.amsl.com>; Wed, 25 Nov 2009 06:00:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.584
X-Spam-Level:
X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnQb17n9BrZf for <ipsec@core3.amsl.com>; Wed, 25 Nov 2009 06:00:44 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 93E4528C242 for <ipsec@ietf.org>; Wed, 25 Nov 2009 06:00:43 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id nAPE0USB015710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ipsec@ietf.org>; Wed, 25 Nov 2009 16:00:30 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nAPE0Uv1014824; Wed, 25 Nov 2009 16:00:30 +0200 (EET)
Date: Wed, 25 Nov 2009 16:00:30 +0200
Resent-From: kivinen@iki.fi
Message-Id: <200911251400.nAPE0Uv1014824@fireball.kivinen.iki.fi>
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
Resent-Message-ID: <19213.14462.928236.781126@fireball.kivinen.iki.fi>
Resent-Date: Wed, 25 Nov 2009 16:00:30 +0200
Resent-To: ipsec@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
From: Tero Kivinen <kivinen@iki.fi>
To: Michael Richardson <mcr@sandelman.ca>
In-Reply-To: <23183.1259080996@marajade.sandelman.ca>
References: <10247.1257346966@marajade.sandelman.ca> <19210.35881.683962.654367@fireball.kivinen.iki.fi> <6762.1258985518@marajade.sandelman.ca> <19211.50148.822367.818236@fireball.kivinen.iki.fi> <23183.1259080996@marajade.sandelman.ca>
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 0 min
X-Total-Time: 0 min
Cc: ipsec@ietf.org
Subject: Re: [IPsec] comments on esp-null-heuristics-01
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Nov 2009 14:00:45 -0000

Michael Richardson writes:
>     Tero> How does that disagree in their definition of flow?
> 
> A flow in the routing and ASIC space is an origin/destination IP address
> pair only.  A microflow is the 5-tuple.

Never heard about microflow before.

Wikipedia says:

    Applied to Internet routers, a flow may be a host-to-host
    communication path, or a socket-to-socket communication identified
    by a unique combination of source and destination addresses and
    port numbers, together with transport protocol (for example, UDP
    or TCP). In the TCP case, a flow may be a virtual circuit, also
    known as a virtual connection or a byte stream.

It also says it could be "a sequence of packets from a source computer
to a destination", which would match other flow definition, so I guess
there is no one standardized definition...

Wikipedia does not know anything about microflows...

RFC2474 seems to be the one which defines microflow, and RFC2991
defines flow to be "represent the granularity at which the router
keeps state", which might be just source and destination addresses, or
it might contain protocol id, and RFC2991 also says that "flow" is not
necessarily synonymous with the term "microflow", but does not also
say it cannot be.

Deep inspection engines usually keep state on granularity of port
numbers, so I do not think the flow definition we use here is
inheritly different from RFC 2991.

Then for example rfc4821 (Packetization Layer Path MTU Discovery)
defines flow to be:

Flow:  A context in which MTU Discovery algorithms can be invoked.
      This is naturally an instance of a Packetization Protocol, for
      example, one side of a TCP connection.

and RFC5626 (Managing Client-Initiated Connections in the Session
Initiation Protocol (SIP)) says:

   Flow:  A Flow is a transport-layer association between two hosts that
      is represented by the network address and port number of both ends
      and by the transport protocol.  For TCP, a flow is equivalent to a
      TCP connection.  For UDP a flow is a bidirectional stream of
      datagrams between a single pair of IP addresses and ports of both
      peers.  With TCP, a flow often has a one-to-one correspondence
      with a single file descriptor in the operating system.

so I do not think there is one agreed on definition of flow.

>     Tero> On the other hand it really does not matter whether it
>     Tero> disagrees or not, this is what we mean by flow in this
>     Tero> document, so as we define it there, it should be clear for
>     Tero> people what we mean by flow. 
> 
> Well, your document will be read by ASIC designers and they already have
> a definition of flow and microflow, and if you want to confuse them,
> then that's fine.

I do not want to use definition that would confuse all others either.
It is bad if one group of people is confused, but don't really want to
confuse other people by using term they do not know (including me).

Perhaps the best way is to say in the terminology definition of flow
that in some context (diffserv and bhp) this is called microflow.
-- 
kivinen@iki.fi