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

Scott Brim <scott.brim@gmail.com> Wed, 06 April 2011 20:20 UTC

Return-Path: <scott.brim@gmail.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 52C563A69B9 for <ipv6@core3.amsl.com>; Wed, 6 Apr 2011 13:20:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.592
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqC5PT7ilRbg for <ipv6@core3.amsl.com>; Wed, 6 Apr 2011 13:20:38 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 383E03A6994 for <ipv6@ietf.org>; Wed, 6 Apr 2011 13:20:38 -0700 (PDT)
Received: by iwn39 with SMTP id 39so2235250iwn.31 for <ipv6@ietf.org>; Wed, 06 Apr 2011 13:22:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=gmail.com; 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 10.231.188.167 with SMTP id da39mr59376ibb.30.1302121342122; Wed, 06 Apr 2011 13:22:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.208.14 with HTTP; Wed, 6 Apr 2011 13:22:02 -0700 (PDT)
In-Reply-To: <201104061849.p36InujN029813@cichlid.raleigh.ibm.com>
References: <E6B0E090-0FC1-482F-A7D3-E47A747539A8@gmail.com> <201104051740.p35HeoU9018197@cichlid.raleigh.ibm.com> <BANLkTin1L7YS3bxxS3fUBpDL+=R9u5oXXg@mail.gmail.com> <201104061849.p36InujN029813@cichlid.raleigh.ibm.com>
From: Scott Brim <scott.brim@gmail.com>
Date: Wed, 6 Apr 2011 16:22:02 -0400
Message-ID: <BANLkTimF=dT+JMkrwJ7b_Q-prZp7joMjYg@mail.gmail.com>
Subject: Re: 6MAN WG Last Call: <draft-ietf-6man-flow-3697bis-02.txt>
To: Thomas Narten <narten@us.ibm.com>
Content-Type: multipart/alternative; boundary=001636c92bc80d3b7404a045c033
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 20:20:39 -0000

On Wed, Apr 6, 2011 at 14:49, Thomas Narten <narten@us.ibm.com>; wrote:

> 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?)
>

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.
>