Re: 6MAN WG Last Call: <draft-ietf-6man-flow-3697bis-02.txt>

Thomas Narten <narten@us.ibm.com> Wed, 06 April 2011 18:48 UTC

Return-Path: <narten@us.ibm.com>
X-Original-To: ipv6@core3.amsl.com
Delivered-To: ipv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3463128C104 for <ipv6@core3.amsl.com>; Wed, 6 Apr 2011 11:48:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.662
X-Spam-Level:
X-Spam-Status: No, score=-106.662 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 DxvIfyN4cnWD for <ipv6@core3.amsl.com>; Wed, 6 Apr 2011 11:48:56 -0700 (PDT)
Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by core3.amsl.com (Postfix) with ESMTP id 4B7313A690A for <ipv6@ietf.org>; Wed, 6 Apr 2011 11:48:56 -0700 (PDT)
Received: from d01dlp01.pok.ibm.com (d01dlp01.pok.ibm.com [9.56.224.56]) by e9.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p36IMw3X003338 for <ipv6@ietf.org>; Wed, 6 Apr 2011 14:22:58 -0400
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 276D438C803C for <ipv6@ietf.org>; Wed, 6 Apr 2011 14:50:25 -0400 (EDT)
Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p36Inxoa135716 for <ipv6@ietf.org>; Wed, 6 Apr 2011 14:50:00 -0400
Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p36InxMD001634 for <ipv6@ietf.org>; Wed, 6 Apr 2011 12:49:59 -0600
Received: from cichlid.raleigh.ibm.com (sig-9-65-245-36.mts.ibm.com [9.65.245.36]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p36InvD9001572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Apr 2011 12:49:58 -0600
Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p36InujN029813; Wed, 6 Apr 2011 14:49:56 -0400
Message-Id: <201104061849.p36InujN029813@cichlid.raleigh.ibm.com>
To: Scott Brim <scott.brim@gmail.com>
Subject: Re: 6MAN WG Last Call: <draft-ietf-6man-flow-3697bis-02.txt>
In-reply-to: <BANLkTin1L7YS3bxxS3fUBpDL+=R9u5oXXg@mail.gmail.com>
References: <E6B0E090-0FC1-482F-A7D3-E47A747539A8@gmail.com> <201104051740.p35HeoU9018197@cichlid.raleigh.ibm.com> <BANLkTin1L7YS3bxxS3fUBpDL+=R9u5oXXg@mail.gmail.com>
Comments: In-reply-to Scott Brim <scott.brim@gmail.com> message dated "Wed, 06 Apr 2011 11:48:57 -0400."
Date: Wed, 06 Apr 2011 14:49:56 -0400
From: Thomas Narten <narten@us.ibm.com>
X-Content-Scanned: Fidelis XPS MAILER
Cc: 6man Mailing List <ipv6@ietf.org>, Brian Haberman <brian@innovationslab.net>, Bob Hinden <bob.hinden@gmail.com>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Apr 2011 18:48:57 -0000

Hi Scott.

Scott Brim <scott.brim@gmail.com>; writes:

> >    A Flow is a sequence of packets originating from a particular
> >    application that should be treated "the same" by the network as
> >    they are forwarded along to their ultimate destination. Packets
> >    within a flow should not be reordered, should not be given
> >    dissimilar QOS treatment, etc. What constitutes a Flow can only be
> >    defined by the application itself.
> >

> Sorry, Thomas, I don't think this will work.  First, I don't think we can
> define a "flow" by what the network should do with it, whatever it
> is.

Well, we are defining a flow by what the network SHOULD NOT do with
packets belonging to the same flow. I.e., packets within a Flow should
not be reordered. That seems to be the key requirement/principle. (Are
there other attributes?)

> If something is definable, then it has attributes independent of how
> other things behave toward it.  It seems that a flow is anything the
> node labels with the same flow label.

Right.

> If so (as in your last sentence), then that's the only definition
> you have.  Also, a flow doesn't necessarily originate from a single
> application.  It could be multiple.

Agreed.

> Some environments don't even have applications.  My inclination
> would be to decline this definition change.

What I think is worth highlighting is that what constitutes a flow can
only be defined by the source of the traffic (i.e., the application(s)
or whatever is at the higher layer). The source node may be using
heuristics to label flows that don't completely match up with what the
application thinks.  That is not necessarily a problem (it's reality),
but I think its useful to make that distinction.

I.e., ideally, the higher layers are what label individual flows. But
if that doesn't happen, the sending node can use heuristics (like
looking at port numbers to fill in the Flow Label) and do pretty well.

Thomas