IETF Logo Mail Archive

Re: [Taps] New rev of udp-usage (01) and review comments on taps-transport-usage-04

Michael Welzl <michawe@ifi.uio.no> Mon, 15 May 2017 05:03 UTC

Return-Path: <michawe@ifi.uio.no>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B820C129476 for <taps@ietfa.amsl.com>; Sun, 14 May 2017 22:03:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.802
X-Spam-Level:
X-Spam-Status: No, score=-2.802 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJv7EPwAV2cj for <taps@ietfa.amsl.com>; Sun, 14 May 2017 22:03:21 -0700 (PDT)
Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D677129B44 for <taps@ietf.org>; Sun, 14 May 2017 21:58:15 -0700 (PDT)
Received: from mail-mx02.uio.no ([129.240.10.43]) by mail-out02.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from <michawe@ifi.uio.no>) id 1dA85F-0004Dd-0n; Mon, 15 May 2017 06:58:13 +0200
Received: from 234.133.189.109.customer.cdi.no ([109.189.133.234] helo=[192.168.1.5]) by mail-mx02.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from <michawe@ifi.uio.no>) id 1dA85E-0009G0-LS; Mon, 15 May 2017 06:58:12 +0200
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (1.0)
From: Michael Welzl <michawe@ifi.uio.no>
X-Mailer: iPhone Mail (14E304)
In-Reply-To: <CAAedzxpwYw_WjGB__uPXgnq7CBEt-fuVnSdNfmff2j-Ua1YXeg@mail.gmail.com>
Date: Mon, 15 May 2017 06:58:10 +0200
Cc: gorry@erg.abdn.ac.uk, "taps@ietf.org" <taps@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <B6CBDDCD-EDAE-4F43-8186-B765323B0CCB@ifi.uio.no>
References: <15106817-a81c-d247-5fad-a67c5faa93f3@erg.abdn.ac.uk> <8A063CAE-55DF-4C38-8631-DC854564DE22@ifi.uio.no> <5915B787.4000307@erg.abdn.ac.uk> <C3B22635-ABDC-4E39-A028-A9B7D479ADA2@ifi.uio.no> <5915E180.2050106@erg.abdn.ac.uk> <CAAedzxpwYw_WjGB__uPXgnq7CBEt-fuVnSdNfmff2j-Ua1YXeg@mail.gmail.com>
To: Erik Kline <ek@google.com>
X-UiO-SPF-Received: Received-SPF: neutral (mail-mx02.uio.no: 109.189.133.234 is neither permitted nor denied by domain of ifi.uio.no) client-ip=109.189.133.234; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.5];
X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 3 sum msgs/h 1 total rcpts 54673 max rcpts/h 54 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-4.9, required=5.0, autolearn=disabled, AWL=0.058, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 30AC7F2E0417FD22DBBD8B4D493BAC63113DF01A
X-UiO-SPAM-Test: remote_host: 109.189.133.234 spam_score: -48 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1425 max/h 13 blacklist 0 greylist 0 ratelimit 0
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/GkWRCtq1UNolu9pMoWaKnyHXG4s>
Subject: Re: [Taps] New rev of udp-usage (01) and review comments on taps-transport-usage-04
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussions on Transport Services <taps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/taps>, <mailto:taps-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/taps/>
List-Post: <mailto:taps@ietf.org>
List-Help: <mailto:taps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/taps>, <mailto:taps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 May 2017 05:03:24 -0000

Well, that may be true, but it's also  not how it should be, according to the rfcs... and apps assuming such misbehavior isn't going to make the situation any better.


today tcp relies on routers not introducing huge reordering, and net admins hopefully know that... so they cause harm by configuring differently.
it would be good if that was the same for the flow label.


Sent from my iPhone

> On 15 May 2017, at 05:10, Erik Kline <ek@google.com> wrote:
> 
> WRT the IPv6 flow label: there really aren't any requirements on semantics that can be relied upon by applications on the wide open Internet.  It's basically just something you can use within cooperating administrative domains.
> 
> That said, it might be nice to be able to influence its value (even if only for applications that are used with an administrative domain).

v2.23.0 | Report a Bug | By Email