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

Brian E Carpenter <> Thu, 07 April 2011 07:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9A3CB28C118 for <>; Thu, 7 Apr 2011 00:36:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.567
X-Spam-Status: No, score=-103.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5WWdL3Z+JZlX for <>; Thu, 7 Apr 2011 00:36:18 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5D0DD28C117 for <>; Thu, 7 Apr 2011 00:36:18 -0700 (PDT)
Received: by wyb29 with SMTP id 29so2159313wyb.31 for <>; Thu, 07 Apr 2011 00:38:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=CoUcQy6G11ngq0PRFLIoyAtkOV0Ujh+cgy1djyZMB1w=; b=nEKofKMRqEEBVrjraIPKqiJf/mTyY1+b4hq3LQljqohTEFTir092yKdGJwLsOH1043 Uk/vYxNlZtVMFza6Qt7MHJGMug2myXNCPvaSlymHWPcaORfjEdr7tpcp2+lq+8ZXyrcx UM10jaIwzrrct5KmvZJ/yDeU5AW995t7yC2SQ=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=rl/C5KFZqdp2N7edgIPiY1Z08QGdYL5jRCJhkd/bDX04Bx2SZPeTN8BRo7BV9OAp5A 8RyZ1FOMZVITtOuZTSaDVn8iOkil9UtZSQNUHBqJ7j2311HO9a7CYVJpADL/EtoQt1MI dF24NGKyVQM9MVHlsqZsKupn8NIAbcxlVpJhY=
Received: by with SMTP id gd20mr506293wbb.210.1302161882156; Thu, 07 Apr 2011 00:38:02 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id y29sm853961wbd.4.2011. (version=SSLv3 cipher=OTHER); Thu, 07 Apr 2011 00:38:00 -0700 (PDT)
Message-ID: <>
Date: Thu, 07 Apr 2011 19:37:45 +1200
From: Brian E Carpenter <>
Organization: University of Auckland
User-Agent: Thunderbird (Windows/20070728)
MIME-Version: 1.0
To: Scott Brim <>
Subject: Re: 6MAN WG Last Call: <draft-ietf-6man-flow-3697bis-02.txt>
References: <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: Thomas Narten <>, Bob Hinden <>, Brian Haberman <>, 6man Mailing List <>
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 07 Apr 2011 07:36:19 -0000

On 2011-04-07 08:22, Scott Brim wrote:
> On Wed, Apr 6, 2011 at 14:49, Thomas Narten <>; wrote:
>> Scott Brim <>; 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?)
> Last sentence first: Yes and the text that was there was
>   "A flow is a sequence of packets sent from a particular source to a
>   particular unicast, anycast, or multicast destination that a node
>   desires to label as a flow."
> ... but what the network should/should not do SHOULD be farther down in the
> draft where such things are already discussed, not in the (very small,
> simple) definition of a flow at the beginning, no?
> But let's not spend a lot of time on it.
> Completely agree on the rest.
>> 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.

We got a pretty clear message a few discussions ago to drop the
speculative text in RFC 3697 about how hosts would support the ability
of applications to do this. So the idea is to be silent on this.