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

Scott Brim <> Wed, 06 April 2011 20:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 52C563A69B9 for <>; Wed, 6 Apr 2011 13:20:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.592
X-Spam-Status: No, score=-103.592 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aqC5PT7ilRbg for <>; Wed, 6 Apr 2011 13:20:38 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 383E03A6994 for <>; Wed, 6 Apr 2011 13:20:38 -0700 (PDT)
Received: by iwn39 with SMTP id 39so2235250iwn.31 for <>; Wed, 06 Apr 2011 13:22:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=9IBKXXDXRJJmQWeRjnknGgqJ90FAS8Ln4lfV7MGZ5SU=; b=HtRJIuh+tg0LaW+Yr8NemsqBQFIsPVR4RtqqaERZlpZZMZ1rGmEB4ialjssiPv7Fj0 O4S3OiTTTMOQmb6GXh1l7eOoPVTY6GjIZCkTB/0LsxzC0PJuX8JUodLsxE00E0P4grZW 5SRuDeHx+RvMPv0tvR/zhW9478B2roPyQbTf8=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=xl1uAUoNuhKwMR0nV/Stz1H7ruVmQul2JFhwsrgEYKUaHAkzDeCOBQ34SqD5umMwaB GWgB5jLM+ei3vPz1BLzQuPhTdkKtCCpix8/+6DpTxN7GAhHi6lJT8IEH3KcgAeVwSiPf lm/a9IrMKTWLIG7wDqTPXFkK7vBX1nw1lsVes=
Received: by with SMTP id da39mr59376ibb.30.1302121342122; Wed, 06 Apr 2011 13:22:22 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 6 Apr 2011 13:22:02 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
From: Scott Brim <>
Date: Wed, 6 Apr 2011 16:22:02 -0400
Message-ID: <>
Subject: Re: 6MAN WG Last Call: <draft-ietf-6man-flow-3697bis-02.txt>
To: Thomas Narten <>
Content-Type: multipart/alternative; boundary=001636c92bc80d3b7404a045c033
Cc: 6man Mailing List <>, Brian Haberman <>, Bob Hinden <>
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: Wed, 06 Apr 2011 20:20:39 -0000

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.