From nobody Fri Nov 3 08:23:02 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB64513FCD4 for ; Fri, 3 Nov 2017 08:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 g2Hvs1k06guO for ; Fri, 3 Nov 2017 08:22:59 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BA9313FC34 for ; Fri, 3 Nov 2017 08:22:59 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id l32so2663904ywh.13 for ; Fri, 03 Nov 2017 08:22:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=qCPVN/mdmueJK/DvWCY85lQhOxAOADBMioYGNYEQuKk=; b=ZekC0l8ek8A1VxEreKUZ3cYD6nzVh7Yq6WlNfKBBKDjEckq1sYSEkV+f4+wOAxW7OR WTh2Hx1KAP5ihA4umpH/uiOu8+jtXBwWi/gK8hTUDgkNBLdrmxlAjpXQjuMCOjVRsnG/ Zayl7SRA5VhSRpKWnyhxGsMi3C423QYARx7c0kIPtqqY2gP0hl9M4tz88PMxvRxp5jQE 0Q4ujGQpW/dM0OyXEV6VFdhkDbNv/kX/Slyn2GpBDvBd2WkSc9Gv3OqnGgjtGnMcW3Ah jLhYGtYRbamVsmay0fmt8LSgzS7hXrKHcWKTvXJYfTpQFq9vMSWcZBdPzjmSEQZoebh7 iZ/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=qCPVN/mdmueJK/DvWCY85lQhOxAOADBMioYGNYEQuKk=; b=PpseZKMkdWKSjz28FB557rl1mkKPwpKjfn1wWn6c4Szpe+xb8fmdscdU9LMsGBxU7Y Up0J+3OvQJHN3W8bkUBBH49E+wH7ZadKJpDyvgk1WiQCUGrlJQ9uL3UP4OKNpMq4sROn +JKZ8hG1icOf8CxLrAJyK+68q6wev/GqDvpldXqOMxLyiuRQcswLU2o38BBLvapz2726 7FT1jHVAvLUZeQLChmQIIzL2zgVyakzBWMI7JOUXzJBBpgBFiWNrvnqPmQTmcwOGpymS 2+Vi8N8RDrtZdpi2FjN6SUbTCfnobu1t0N+C21an6hY9mrQpgPY34eOeeWj6BdAoXVo+ 42Jg== X-Gm-Message-State: AMCzsaW3eUiBPjtxCNVk7ena/2+C3Ux2AoW73AuMRx1Yakh3Uj/yEcM/ qzxV5ByGvRVnx5bLieMfRL32ZjAHR2apUQNLN8SRlg== X-Google-Smtp-Source: ABhQp+TdtI+mibvwBDWuSgVL3axVNJ7QMCyM5dgp9QAH71t23jCAdnsBMrlTXQeQy4ksOcdt2TClN18jTRI26LQghuI= X-Received: by 10.37.214.136 with SMTP id n130mr4593465ybg.255.1509722578266; Fri, 03 Nov 2017 08:22:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.162.204 with HTTP; Fri, 3 Nov 2017 08:22:57 -0700 (PDT) From: Spencer Dawkins at IETF Date: Fri, 3 Nov 2017 10:22:57 -0500 Message-ID: Subject: TSVAREA Agenda for IETF 100 posted, TSV AD Office Hours scheduled To: "tsv-area@ietf.org >> tsv-area@ietf.org" Cc: Mirja Kuehlewind Content-Type: multipart/alternative; boundary="94eb2c06573cfcaf30055d15adbe" Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 15:23:02 -0000 --94eb2c06573cfcaf30055d15adbe Content-Type: text/plain; charset="UTF-8" Dear TSVers, Mirja and I have posted the TSVAREA agenda at https://datatracker.ietf.org/meeting/100/materials/agenda-100-tsvarea/. The meeting is on Thursday afternoon at 18:10 in the Padang room. Our meeting at IETF 100 will be short (one hour), and will focus on implementation topics, and on coordinating specification work with interop testing. We will have some open mike time as well. Mirja and I have also scheduled TSV AD office hours for Wednesday at 15:20-16:50 in the Clark room. If you have questions, or want to provide feedback, or have work that's gotten stuck, and pretty much anything else about TSV topics, you're invited - and if you let us know that you're coming, and what you need to talk about, we'll even be prepared. Thanks, and travel safely, for those of you who are traveling. Spencer, as AD --94eb2c06573cfcaf30055d15adbe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear TSVers,

Mirja and I have posted th= e TSVAREA agenda at=C2=A0https://datatracker.ietf.org/meeting/100/m= aterials/agenda-100-tsvarea/. The meeting is on Thursday afternoon at 1= 8:10 in the Padang room. Our meeting at IETF 100 will be short (one hour), = and will focus on implementation topics, and on coordinating specification = work with interop testing. We will have some open mike time as well.
<= div>
Mirja and I have also scheduled TSV AD office hours for Wedne= sday at 15:20-16:50 in the Clark room. If you have questions, or want to pr= ovide feedback, or have work that's gotten stuck, and pretty much anyth= ing else about TSV topics, you're invited - and if you let us know that= you're coming, and what you need to talk about, we'll even be prep= ared.

Thanks, and travel safely, for those of you who ar= e traveling.=C2=A0

Spencer, as AD
--94eb2c06573cfcaf30055d15adbe-- From nobody Wed Nov 8 09:42:54 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE539128CD5 for ; Wed, 8 Nov 2017 09:42:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 b3fvdZRKJkEl for ; Wed, 8 Nov 2017 09:42:52 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E40F1294A1 for ; Wed, 8 Nov 2017 09:42:51 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 9200A58C4B9 for ; Wed, 8 Nov 2017 18:42:47 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 7697DB0D0FF; Wed, 8 Nov 2017 18:42:47 +0100 (CET) Date: Wed, 8 Nov 2017 18:42:47 +0100 From: Toerless Eckert To: tsv-area@ietf.org Subject: TCP behavior across WiFi pointers ? Message-ID: <20171108174247.GM19390@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 17:42:54 -0000 Any pointers to work analyzing the differences in behavior when TCP is run across WiFi as opposed to wired ? Especially with WiFi in the home ? I am primarily thinking that there could be a higher demand for TCP (end-to-end) retransmissions when using WiFi because the L2/WiFi local retransmissions are insufficient. And if so, what the characteristics of those end-to-end retransmissions is (would assume they would be larger than N msec, where N is whatever the L2/wifi protection window is, which unfortunately i don't know). Asking because we've got the poor "must-sit-in-back-of-the-bus" traffic called IP multicast that is not protected by L2/wifi retransmissions at all and now we're wondering if carrying it over TCP as a workaround could help, and therefore trying to educate myself on specific known issue left when running traffic over TCP over WiFi. If any other TSV or other WG mailing list might be a better place to ask. pls. let me know. Thank! Toerless From nobody Wed Nov 8 10:33:11 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39CB7129ABD; Wed, 8 Nov 2017 10:33:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 ESKaAZd3D6jm; Wed, 8 Nov 2017 10:33:07 -0800 (PST) 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 BF58B129AAD; Wed, 8 Nov 2017 10:32:49 -0800 (PST) Received: from mail-mx04.uio.no ([129.240.10.25]) by mail-out02.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1eCV9c-0005aO-0n; Wed, 08 Nov 2017 19:32:48 +0100 Received: from 93-58-133-64.ip158.fastwebnet.it ([93.58.133.64] helo=[10.0.0.6]) by mail-mx04.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1eCV9b-0003lR-GV; Wed, 08 Nov 2017 19:32:47 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: TCP behavior across WiFi pointers ? From: Michael Welzl In-Reply-To: <20171108174247.GM19390@faui40p.informatik.uni-erlangen.de> Date: Wed, 8 Nov 2017 19:32:47 +0100 Cc: tsv-area@ietf.org, iccrg@irtf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20171108174247.GM19390@faui40p.informatik.uni-erlangen.de> To: Toerless Eckert X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx04.uio.no: 93.58.133.64 is neither permitted nor denied by domain of ifi.uio.no) client-ip=93.58.133.64; envelope-from=michawe@ifi.uio.no; helo=[10.0.0.6]; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.043, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 21BAF2EF7BF26A53AD3613DAC7D1F9C1179A4BA2 Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 18:33:10 -0000 I would think that 1) there are probably pointers, and 2) the people who = have them should be on the ICCRG list, which I=E2=80=99m cc=E2=80=99ing. I suggest for this to be the last email that includes tsvarea so that = the thread entirely moves to ICCRG. > On Nov 8, 2017, at 6:42 PM, Toerless Eckert = wrote: >=20 > Any pointers to work analyzing the differences in behavior when TCP is = run > across WiFi as opposed to wired ? Especially with WiFi in the home ? >=20 > I am primarily thinking that there could be a higher demand for > TCP (end-to-end) retransmissions when using WiFi because the L2/WiFi > local retransmissions are insufficient. And if so, what the = characteristics > of those end-to-end retransmissions is (would assume they would be = larger > than N msec, where N is whatever the L2/wifi protection window is, = which > unfortunately i don't know). >=20 > Asking because we've got the poor "must-sit-in-back-of-the-bus" = traffic > called IP multicast that is not protected by L2/wifi retransmissions = at > all and now we're wondering if carrying it over TCP as a workaround > could help, and therefore trying to educate myself on specific known > issue left when running traffic over TCP over WiFi. >=20 > If any other TSV or other WG mailing list might be a better place to > ask. pls. let me know. >=20 > Thank! > Toerless >=20 From nobody Wed Nov 8 10:37:48 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA72129AD5 for ; Wed, 8 Nov 2017 10:37:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mjmontpetit-com.20150623.gappssmtp.com 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 KaDJ5TvlY9zc for ; Wed, 8 Nov 2017 10:37:39 -0800 (PST) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90114129AC5 for ; Wed, 8 Nov 2017 10:37:39 -0800 (PST) Received: by mail-it0-x230.google.com with SMTP id p138so8041584itp.2 for ; Wed, 08 Nov 2017 10:37:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mjmontpetit-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nWEu4s74hjAHpYEPQC9fp5kKJ3jEGDFL0SKNFiwcMZ0=; b=psicQKWTv3Y3rLgZ7gLfjEuCfRTzRzZ2AVfgVxbCuLb0tGGVHl1qtK1tbn1oM2lxel R/GcrOXhCjbP3wFdFqQTZz57ZB/2Ai9HWR0vBe13SzUGo270tbljNDm1K5npElV/G/Ph Iv4j6wbkLFOpLEJMs1mpTvZ6Tc7uk8MpoEi7y6vE23hvSU4MhtTYX8MGKx19La46tgyl xPwJdNupGYWBxBILHrz8bwIb8dyJnVMx0mxptbDlNyJEU3TW4+HwlICT9Hf8gCPT2Hs6 Ehwa7v38b3QUd4ovPQWpcfC6qfMADHIR2QSqdKUOIVXLg6nFT9IdzX5fs8/zVycXsbKI wxNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nWEu4s74hjAHpYEPQC9fp5kKJ3jEGDFL0SKNFiwcMZ0=; b=WCN6r9LnwY3ZMTM0PNAvnHPbotu8MTV7nDPZEMnzgvH4qP/dPV5srb2rhZvThTILEB EwRoiVdK1K/2pze8qWLVVpu0TKPsce5ht4auMlMDL/AyYFh649XJnxEBOmkGtBCFItHV 8lUsoRKkNYQO+zkATyPuzcJwDXKppA/1JqhUoJs7qLBiws7QqsTAbo6HiS7OR1Agv2d4 g/iRDDLCznwEMxAnIvkkicM8nKAflE5e2hOBE2zSqLywYldg7tOwGB7T8qcUa1H2a3nG thw6XVSKm+koyq+E1ExpqZR984PbKFzo+GoE+8HKV9tVAcXWUMGstd/pG5Y9b47gNEFN lULw== X-Gm-Message-State: AJaThX6nGXoQT362w03Bq23oA7DooWBjKgWuJ7s9K577mUPrQ9kFaO5L vPs1UaY6jAO6vcor2NuC7dfgzXTO9hg= X-Google-Smtp-Source: ABhQp+RQRtP2v8bQO7Be6+iweaKU6XlAlo/NpJejV5CkFwE239MjxeP3JlgUwUSWY4GidVZ7jgJPaw== X-Received: by 10.36.82.204 with SMTP id d195mr1909365itb.23.1510166258748; Wed, 08 Nov 2017 10:37:38 -0800 (PST) Received: from [10.189.108.71] ([192.54.222.28]) by smtp.gmail.com with ESMTPSA id s129sm2515442itb.22.2017.11.08.10.37.37 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 08 Nov 2017 10:37:38 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: [iccrg] TCP behavior across WiFi pointers ? From: Marie-Jose Montpetit In-Reply-To: Date: Wed, 8 Nov 2017 13:37:37 -0500 Cc: Toerless Eckert , iccrg IRTF list , tsv-area@ietf.org, nwcrg@irtf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2F98AEC5-9313-437C-8E7B-246BB2238A8C@mjmontpetit.com> References: <20171108174247.GM19390@faui40p.informatik.uni-erlangen.de> To: Michael Welzl X-Mailer: Apple Mail (2.3124) Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 18:37:42 -0000 I also copy the nwcrg list where a ton of people have looked at TCP over = wifi. mjm > On Nov 8, 2017, at 1:32 PM, Michael Welzl wrote: >=20 > I would think that 1) there are probably pointers, and 2) the people = who have them should be on the ICCRG list, which I=E2=80=99m cc=E2=80=99in= g. >=20 > I suggest for this to be the last email that includes tsvarea so that = the thread entirely moves to ICCRG. >=20 >=20 >> On Nov 8, 2017, at 6:42 PM, Toerless Eckert = wrote: >>=20 >> Any pointers to work analyzing the differences in behavior when TCP = is run >> across WiFi as opposed to wired ? Especially with WiFi in the home ? >>=20 >> I am primarily thinking that there could be a higher demand for >> TCP (end-to-end) retransmissions when using WiFi because the L2/WiFi >> local retransmissions are insufficient. And if so, what the = characteristics >> of those end-to-end retransmissions is (would assume they would be = larger >> than N msec, where N is whatever the L2/wifi protection window is, = which >> unfortunately i don't know). >>=20 >> Asking because we've got the poor "must-sit-in-back-of-the-bus" = traffic >> called IP multicast that is not protected by L2/wifi retransmissions = at >> all and now we're wondering if carrying it over TCP as a workaround >> could help, and therefore trying to educate myself on specific known >> issue left when running traffic over TCP over WiFi. >>=20 >> If any other TSV or other WG mailing list might be a better place to >> ask. pls. let me know. >>=20 >> Thank! >> Toerless >>=20 >=20 > _______________________________________________ > iccrg mailing list > iccrg@irtf.org > https://www.irtf.org/mailman/listinfo/iccrg From nobody Mon Nov 27 00:12:12 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3678126D85; Mon, 27 Nov 2017 00:12:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.com 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 NDQp_B8bgmgz; Mon, 27 Nov 2017 00:12:03 -0800 (PST) Received: from mx142.netapp.com (mx142.netapp.com [IPv6:2620:10a:4005:8000:2306::b]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AE921200F3; Mon, 27 Nov 2017 00:12:03 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.44,463,1505804400"; d="asc'?scan'208,217";a="224698798" Received: from hioexcmbx01-prd.hq.netapp.com ([10.122.105.34]) by mx142-out.netapp.com with ESMTP; 27 Nov 2017 00:12:02 -0800 Received: from VMWEXCCAS08-PRD.hq.netapp.com (10.122.105.26) by hioexcmbx01-prd.hq.netapp.com (10.122.105.34) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 27 Nov 2017 00:12:02 -0800 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS08-PRD.hq.netapp.com (10.122.105.26) with Microsoft SMTP Server (TLS) id 15.0.1320.4 via Frontend Transport; Mon, 27 Nov 2017 00:12:02 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FCskL6NEOWTuAih90lUHjD0DyKPDTvfQKIeco/Z9Hgo=; b=UHeYXCy2n71ieJum/TCE9s3RBTN3Lm5HCWx/fXIJRmAcHmwOdMs2fx+6bZvfEvJhBNBxPP5rYJr0o1A0FfJ/BrmiXHFLLc1EXlleoVySkkvhszxWTmQAAFBLv0OiZKt6aVkpEVdEUJ/eHDdngjcYOVMtSURdowBbAHGqx92oy+U= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB1761.namprd06.prod.outlook.com (10.162.224.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.4; Mon, 27 Nov 2017 08:12:00 +0000 Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) by BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) with mapi id 15.20.0260.006; Mon, 27 Nov 2017 08:12:00 +0000 From: "Eggert, Lars" To: "MORTON, ALFRED C (AL)" CC: QUIC WG , "tsv-area@ietf.org" Subject: Re: Spin bit discussion - where we're at Thread-Topic: Spin bit discussion - where we're at Thread-Index: AQHTY2jqp1VdukIM2U+G9HAjuBI8daMgHeUAgAANHICAAAmEgIAABm6AgAbXQwCAANXCAA== Date: Mon, 27 Nov 2017 08:11:59 +0000 Message-ID: <791D0F33-4CB7-4049-AF29-174E41C1FD2E@netapp.com> References: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> <4D7F4AD313D3FC43A053B309F97543CF4904F2FD@njmtexg5.research.att.com> In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CF4904F2FD@njmtexg5.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.4.7) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [217.70.211.15] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB1761; 6:dkAdqvG2ODZatG2XvDoxzysB494k2MZ7rpwMjf+AFP+5v2JUP3DVyQMHZTb1LmC+zieYwlHA2EI+JCtPDcq8JcdY0SuVxHx4+GoL0aFS9FQsAoeuX4+hGgSwPTXO1PDL8BEGfhgXfP3UHhzdKavxtFIfWbX7PyCdW+npbPBdaagaMuCoR/VNQuox1MT+1Tbt0Pv/qQJXnWIgqDhpATZM9IxaXCPo6QLUUkHcj2sFIAM0I9laS1dI5bSpwW7RbgmJgeBLey+BQQV8CxZO2CeBoJe/EkZSu8tgp4LDbxaVZiHko0qhZacxDttrnY1qxhMkD8jqEZejJiaQ0PyYX7vkkd//16+chCu8QgGl5xvF0tM=; 5:BCUoDNoZ6Kv/xdFKwj2jkAIROWauDEZKv7gPu0WVAO1sN0U7zt36Gr9iXzWhZLwHVWNNOaTi8PohIRFkq43RWSsFPHKdk9cRAvOFQ5ev2kKgYjvpGgvrP8wDx+QdDbi2W1JPNZNdYX0AgkNCuMO0EfQBi5POCvtKEOctQ5fcSvM=; 24:C9OhhOJOrlIhK/vcZWQqrY5Sj/CBH/vOmoqZ6V18Tgt6IsFUm635m1kU1zy4k8FYKs/nn51B6tuPFfMcJ9oh54y//3nwep2WMTl8YAJy784=; 7:Jp+s99vtzNNdcCMUO47KnVD/4/RCXJ1kFpOr5Hje+PT4rhE21t15vuk+0uXMMeMSJOfmmkkS5SzYJkKjPQyvlmYfyQ+3O2j4WHUIKMWxrD7dXzOrt69F3PiRjKb3VmkIdbEUOGERvv7y8NMNktMGxHuFwdjExA/lLLnx7ZUjwfKLlQN9oduq0bHAvuut3bgzSeSLEI0QzU8r6r+NbtyurSfQhEqHxiEQMbbaKPou8OLqvOTgtRN21dcMvhiwat7p x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 96165ea6-394d-4470-b27b-08d5356e88e2 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199)(49563074); SRVR:BLUPR06MB1761; x-ms-traffictypediagnostic: BLUPR06MB1761: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(97927398514766); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(3231022)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123555025)(20161123558100)(20161123560025)(6072148)(201708071742011); SRVR:BLUPR06MB1761; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BLUPR06MB1761; x-forefront-prvs: 0504F29D72 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(366004)(377424004)(199003)(189002)(24454002)(2900100001)(101416001)(66066001)(86362001)(53546010)(81156014)(81166006)(229853002)(82746002)(5660300001)(6486002)(77096006)(76176999)(105586002)(97736004)(68736007)(102836003)(6116002)(2950100002)(50986999)(99936001)(33656002)(189998001)(3846002)(25786009)(4001150100001)(478600001)(8936002)(3280700002)(2906002)(6916009)(6246003)(36756003)(54906003)(316002)(6512007)(99286004)(54896002)(236005)(93886005)(14454004)(53936002)(7736002)(8676002)(3660700001)(106356001)(50226002)(6506006)(4326008)(83716003)(6436002)(57306001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB1761; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_A610358F-2280-402B-BF2A-FF6BCABA982E"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 96165ea6-394d-4470-b27b-08d5356e88e2 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Nov 2017 08:11:59.9213 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1761 X-OriginatorOrg: netapp.com Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 08:12:05 -0000 --Apple-Mail=_A610358F-2280-402B-BF2A-FF6BCABA982E Content-Type: multipart/alternative; boundary="Apple-Mail=_96F5E68A-9231-4952-95C5-330A01141798" --Apple-Mail=_96F5E68A-9231-4952-95C5-330A01141798 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2017-11-26, at 20:26, MORTON, ALFRED C (AL) wrote: > Question: Is there a privacy analysis of present ECN available? > (a search yielded many results with Missing: privacy) not that I'm aware of; CC'ing tsv-area@ for some broader input. (On first glance, the - user - privacy aspects here seem to be much more = contained, since ECN is mostly about the network exposing information to = the end systems, and not vice versa.) Lars --Apple-Mail=_96F5E68A-9231-4952-95C5-330A01141798 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi,

On = 2017-11-26, at 20:26, MORTON, ALFRED C (AL) <acmorton@att.com> = wrote:
Question: Is there a = privacy analysis of present ECN available?
(a search yielded many results with Missing: = privacy)

not that I'm aware of; CC'ing tsv-area@ for = some broader input.

(On first glance, the - user - privacy aspects here seem to = be much more contained, since ECN is mostly about the network exposing = information to the end systems, and not vice versa.)

Lars
= --Apple-Mail=_96F5E68A-9231-4952-95C5-330A01141798-- --Apple-Mail=_A610358F-2280-402B-BF2A-FF6BCABA982E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAlobyM8ACgkQVLXDCb9w wVeQhw/9GlQlE/Rn1Gl9lg8IOCP11k/pjEW/0Q1KLL9ENfTgO409ejsssIOzNbsK X9G/ZPiTpPtTtiu/UrU7G+W1kLsbXf8wl6dae0897oOlMT5J/qhih7yLJeljXkdC kMNwb7srx1HW77AhPifA+QL/0WONOS3HeRGPOO/8eWzA9InkD86iM06fIeSVQsMe ylGPf6PNmJSgyA2jZCjsff0ReIHQsGfA4OnC5QkJsqCoAbaDISp39oiCbvw7uly5 bs1XvekCedGQxpHMboKBsftGQcQIHwZT1a2fM/zAInzxMENfxXuDiIqwcKKnOMnr oRyzEtZ8bdLfJ75Nd1IkHkZ3dYeH7fYD1T9MmgZnaSlZ9FVohJzwWuXtX3+weFQi hn3xec4fWcRQ/xkLXSNaL39Vaw2B4RJBImo+oxg2BPpzuL1q0oLRBjHRsIISlIWt sp/UJXO5ORGBzL9+C6B1fat1pCsfh046EO3GkRWWQ7z4he3+rJe2a/mLWSfY0Zf3 YCp2A82FiCZEexmv+sWJxysEm2P/+mwlnGGc/HoZAoGdnRkV/wE96FPRPpVKaPeJ zGJ5ovEIFpYC0XbJmgQZUpastuJgSegk3N3JmA/UYXC4r7Aa7QgNhJZiMJd0KOob Nl9JmOZpTQCmBsLO7E7lYASycssUrt/MfHuywbou287v9sKpy3E= =qseS -----END PGP SIGNATURE----- --Apple-Mail=_A610358F-2280-402B-BF2A-FF6BCABA982E-- From nobody Tue Nov 28 15:53:01 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6151292F5; Tue, 28 Nov 2017 15:53:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=QdwXIgEy; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=mqP//NBE 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 woHOodYh-Ptz; Tue, 28 Nov 2017 15:52:58 -0800 (PST) Received: from esa2.dell-outbound.iphmx.com (esa2.dell-outbound.iphmx.com [68.232.149.220]) (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 680201292AE; Tue, 28 Nov 2017 15:52:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1511913178; x=1543449178; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=aT+Ok+t8pdj4DBCn8EcKNP9eSHCoU5O7sTSOfTbbp9k=; b=QdwXIgEyBrMcDENkpPLtSYiGZ7bDdWfbalqa54R/Jgf865apOnmad6qg /D78z8AzupLMLV7SdMjODzAjVGhm/oOPOe2nBTHIPKljs6J4/b4zoe0eM fWDkkVoo3XpsU8LL0VEHqG3X1uYWHsaDNF1RlfOPP1Rmzs5brmo7jhJnC A=; IronPort-PHdr: =?us-ascii?q?9a23=3AJRFYNRCH/64R7iz24PCVUyQJP3N1i/DPJgcQr6Af?= =?us-ascii?q?oPdwSPX/rsbcNUDSrc9gkEXOFd2CrakV26yO6+jJYi8p2d65qncMcZhBBVcuqP?= =?us-ascii?q?49uEgeOvODElDxN/XwbiY3T4xoXV5h+GynYwAOQJ6tL1LdrWev4jEMBx7xKRR6?= =?us-ascii?q?JvjvGo7Vks+7y/2+94fdbghMhzexe69+IAmrpgjNq8cahpdvJLwswRXTuHtIfO?= =?us-ascii?q?pWxWJsJV2Nmhv3+9m98p1+/SlOovwt78FPX7n0cKQ+VrxYES8pM3sp683xtBnM?= =?us-ascii?q?VhWA630BWWgLiBVIAgzF7BbnXpfttybxq+Rw1DWGMcDwULs5Qiqp4bt1RxD0iS?= =?us-ascii?q?cHLz85/3/Risxsl6JQvRatqwViz4LIfI2ZMfxzdb7fc9wHX2pMRsZfWTJcDIOg?= =?us-ascii?q?YYUBDOQBMuRZr4bhqFQDtgGxCRWoCe711jNEmmH60Ksn2OohCwHG2wkgEsoAvH?= =?us-ascii?q?nJqNX6LrsdUeOtwKLVwzvMde1W2Tbg54TGbxsspv+CUqhuccrQ1EYjDR7IjlGK?= =?us-ascii?q?poP5PDOYzfkCvHaf7+pkT+6gl2knqwRorzWp28wiiZHJi5oUx13H7yl13og4Kc?= =?us-ascii?q?OiREJmYdOpH4FcuiWZOoduX88uX3tktDg0x7AFo5K2cycHxI46yxPRaPGLa4aI?= =?us-ascii?q?7QzgWeqNJDp1gXFodb27iha89EWtyvDzWdOq3FtPsyZJj8LDu3UC2hHd6cWKSv?= =?us-ascii?q?1w9Vq71zmVzQDc8ORELFgxlarcNpEu3KY9loEWsUTfBi/2n1j2jLOOekUk5Oeo?= =?us-ascii?q?7+Pnb634qZ+HLYB5hRvyPbkwlcy7BeQ0Kw8OX3WH+eun073j4Ev5T6hUgvEsk6?= =?us-ascii?q?nZqJDaJcEUp6KjHwBV1YMj5w6+DzegztsYgWEKIVNGdR6dkYTkNU/CLOrlAfq/?= =?us-ascii?q?jFmgijNmyvPeMr3kGJrNL3zDkLn7fbZ67k5R0AQ9wspB55JVF74NOu/+Wkvru9?= =?us-ascii?q?PEDR80KBG7zPjjCNV5zI8RRWWPAqqBPKPIrVCI/v4vI/WLZIINpDb9MOYl6+f0?= =?us-ascii?q?gn8jh1ASZ7Kk3ZoJZ3CkEPRqOUKZYWDjgt0ZC2cFohI+TPD2iF2FSTNTfmuyX6?= =?us-ascii?q?Mg6TwgCYKpE5vDRo63jLyGxie7Ec4eWmcTQH2DHnrya8HMf/4Wc2jadstoiCcs?= =?us-ascii?q?U7W9Qpc5kxqpsVm+g/BCCdDo3Qtc/bvH+uJYy6X43VEb0X0+R5CU2GSKVX1zmE?= =?us-ascii?q?sBWyNw16d69x9T0FCGhOJSh/VTFpgby/pXUwtwfcrwxvJ7B5bYXgvKff+FRVKi?= =?us-ascii?q?BN6hBGdiHZoK39YSbhMlSJ2ZhRfZ0n/vWudNmg=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2EuAAC59R1ah2Ka6ERcGgEBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYJKIoEmEG4nB44YjxmBfZZzgU5DCoU7AoUGPxgBAQEBAQEBAQEBAhA?= =?us-ascii?q?BAQEIDQkIKC+COCQBDkghBTIBAQEBAQEBAQEBAQEBAQEBAQEXAj0TAQEYAQEBA?= =?us-ascii?q?QMtEx8aAQ8CAQgRBAEBCx0HMhQJCAIEDgUIiTZkAalGgxCHWAEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBARUIgz2BNlOBV4UThSE0gxCCMotClwkGAqhblhMCBAIEBQIag?= =?us-ascii?q?TofYIErb4J4CYJZgXN3iVaBFAEBAQ?= X-IPAS-Result: =?us-ascii?q?A2EuAAC59R1ah2Ka6ERcGgEBAQEBAgEBAQEIAQEBAYJKIoE?= =?us-ascii?q?mEG4nB44YjxmBfZZzgU5DCoU7AoUGPxgBAQEBAQEBAQEBAhABAQEIDQkIKC+CO?= =?us-ascii?q?CQBDkghBTIBAQEBAQEBAQEBAQEBAQEBAQEXAj0TAQEYAQEBAQMtEx8aAQ8CAQg?= =?us-ascii?q?RBAEBCx0HMhQJCAIEDgUIiTZkAalGgxCHWAEBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?RUIgz2BNlOBV4UThSE0gxCCMotClwkGAqhblhMCBAIEBQIagTofYIErb4J4CYJ?= =?us-ascii?q?ZgXN3iVaBFAEBAQ?= Received: from esa4.dell-outbound2.iphmx.com ([68.232.154.98]) by esa2.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Nov 2017 17:52:57 -0600 From: "Black, David" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa4.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Nov 2017 05:52:56 +0600 Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id vASNqtKg006862 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 28 Nov 2017 18:52:56 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com vASNqtKg006862 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1511913176; bh=+hS3LKYJWLDEfuIB1y8+H/SRUCQ=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=mqP//NBEvx0UlyxY2Txunm5xOeOePhJRD3oLdyVvANLhQx7ua9dV64arPZCsKCnIU 9m1IiW7e+YJFbwoHh3VL6uuQDkbJiasD7eY626WzIiwxnzRplTRUYUiu8WotJ6KpXD RkDSSkmVgv3O03I4cPqhIo00EbnlrNTzX2VHLgTY= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com vASNqtKg006862 Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd55.lss.emc.com (RSA Interceptor); Tue, 28 Nov 2017 18:52:41 -0500 Received: from MXHUB309.corp.emc.com (MXHUB309.corp.emc.com [10.146.3.35]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id vASNqfSv031881 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Tue, 28 Nov 2017 18:52:41 -0500 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB309.corp.emc.com ([10.146.3.35]) with mapi id 14.03.0352.000; Tue, 28 Nov 2017 18:52:41 -0500 To: "Eggert, Lars" , "MORTON, ALFRED C (AL)" CC: QUIC WG , "tsv-area@ietf.org" Subject: RE: Spin bit discussion - where we're at Thread-Topic: Spin bit discussion - where we're at Thread-Index: AQHTY2jqp1VdukIM2U+G9HAjuBI8daMgHeUAgAANHICAAAmEgIAABm6AgAbXQwCAANXCAIACjivQ Date: Tue, 28 Nov 2017 23:52:40 +0000 Message-ID: References: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> <4D7F4AD313D3FC43A053B309F97543CF4904F2FD@njmtexg5.research.att.com> <791D0F33-4CB7-4049-AF29-174E41C1FD2E@netapp.com> In-Reply-To: <791D0F33-4CB7-4049-AF29-174E41C1FD2E@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.138] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949362FD920D9MX307CL04corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd04.lss.emc.com X-RSA-Classifications: public Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 23:53:00 -0000 --_000_CE03DB3D7B45C245BCA0D243277949362FD920D9MX307CL04corpem_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > (On first glance, the - user - privacy aspects here seem to be much more = contained, since ECN is mostly about the network exposing information to th= e end systems, and not vice versa.) That sounds like the right high-level summary. The fact that a transport p= rotocol implementation supports ECN does not intrinsically expose any infor= mation about the user to the network. The primary information flow is conge= stion information flowing from the network to the endpoints. Thanks, --David From: tsv-area [mailto:tsv-area-bounces@ietf.org] On Behalf Of Eggert, Lars Sent: Monday, November 27, 2017 3:12 AM To: MORTON, ALFRED C (AL) Cc: QUIC WG ; tsv-area@ietf.org Subject: Re: Spin bit discussion - where we're at Hi, On 2017-11-26, at 20:26, MORTON, ALFRED C (AL) > wrote: Question: Is there a privacy analysis of present ECN available? (a search yielded many results with Missing: privacy) not that I'm aware of; CC'ing tsv-area@ for some broader input. (On first glance, the - user - privacy aspects here seem to be much more co= ntained, since ECN is mostly about the network exposing information to the = end systems, and not vice versa.) Lars --_000_CE03DB3D7B45C245BCA0D243277949362FD920D9MX307CL04corpem_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> (On first glance, the - user - privacy aspects here seem to be m= uch more contained, since ECN is mostly about the network exposing informat= ion to the end systems, and not vice versa.)

 

That sounds like the right high-level= summary.  The fact that a transport protocol implementation supports = ECN does not intrinsically expose any information about the user to the network. The primary information flow is congestion inform= ation flowing from the network to the endpoints.

 

Thanks, --David

 

From: tsv-area [mailto:tsv-area-boun= ces@ietf.org] On Behalf Of Eggert, Lars
Sent: Monday, November 27, 2017 3:12 AM
To: MORTON, ALFRED C (AL) <acmorton@att.com>
Cc: QUIC WG <quic@ietf.org>; tsv-area@ietf.org
Subject: Re: Spin bit discussion - where we're at<= /p>

 

Hi,

 

On 2017-11-26, at 20:26, MORTON, ALFRED C (AL) <<= a href=3D"mailto:acmorton@att.com">acmorton@att.com> wrote:

Question: Is there a privacy analysis of present ECN available?

(a search yielded many results with Missing: privac= y)

 

not that I'm aware of; CC'ing tsv-area@ for some bro= ader input.

 

(On first glance, the - user - privacy aspects here = seem to be much more contained, since ECN is mostly about the network expos= ing information to the end systems, and not vice versa.)

 

Lars

--_000_CE03DB3D7B45C245BCA0D243277949362FD920D9MX307CL04corpem_-- From nobody Tue Nov 28 16:26:50 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71224127735; Tue, 28 Nov 2017 16:26:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=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 4ZICJcyyawul; Tue, 28 Nov 2017 16:26:39 -0800 (PST) Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6BA1127136; Tue, 28 Nov 2017 16:26:38 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id DFB0234096A; Wed, 29 Nov 2017 01:26:36 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/18338.6335); Wed, 29 Nov 2017 01:26:33 +0100 (CET) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Wed, 29 Nov 2017 01:26:33 +0100 (CET) Received: from [114.175.86.34] (account ietf@trammell.ch HELO [192.168.1.183]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 37572338; Wed, 29 Nov 2017 01:26:32 +0100 From: "Brian Trammell (IETF)" Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_1F2F7D2B-855A-4955-93C0-24173DC72004"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Spin bit discussion - where we're at Date: Wed, 29 Nov 2017 09:26:29 +0900 In-Reply-To: Cc: "Eggert, Lars" , Al Morton , QUIC WG , "tsv-area@ietf.org" To: "Black, David" References: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> <4D7F4AD313D3FC43A053B309F97543CF4904F2FD@njmtexg5.research.att.com> <791D0F33-4CB7-4049-AF29-174E41C1FD2E@netapp.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 00:26:42 -0000 --Apple-Mail=_1F2F7D2B-855A-4955-93C0-24173DC72004 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi, David, > On 29 Nov 2017, at 08:52, Black, David wrote: >=20 > > (On first glance, the - user - privacy aspects here seem to be much = more contained, since ECN is mostly about the network exposing = information to the end systems, and not vice versa.) >=20 > That sounds like the right high-level summary. The fact that a = transport protocol implementation supports ECN does not intrinsically = expose any information about the user to the network. The primary = information flow is congestion information flowing from the network to = the endpoints. There are three possible states for an ECN negotiation: not attempted, = failed, and succeeded. Each of these can add a fractional bit of = information about the client and server TCP implementations. If a server = negotiates ECN, you can be reasonably certain that it supports ECN, and = can leverage the observations that sysadmins love defaults and servers = are mostly Linux these days to figure out whether it's running a kernel = before or after server side defaults were turned on. Long-term observation of the ECN negotiation attempts of a client can be = used to determine if the client is using probabilistic negotiation by = default; i.e. is an Apple device of a certain vintage. These are fractional bits of fingerprinting information, though, if = that. I'm almost certain (but won't take the time to do the research = now) that any of these observations would be useless. Anyone in a = position to make them could also get much more information about the = behavior of the TCP stacks at each end, such that the ECN bits add = negligible information. cf. p0f, if that's still a thing. Cheers, B >=20 > Thanks, --David >=20 > From: tsv-area [mailto:tsv-area-bounces@ietf.org] On Behalf Of Eggert, = Lars > Sent: Monday, November 27, 2017 3:12 AM > To: MORTON, ALFRED C (AL) > Cc: QUIC WG ; tsv-area@ietf.org > Subject: Re: Spin bit discussion - where we're at >=20 > Hi, >=20 > On 2017-11-26, at 20:26, MORTON, ALFRED C (AL) = wrote: >=20 > Question: Is there a privacy analysis of present ECN available? > (a search yielded many results with Missing: privacy) >=20 > not that I'm aware of; CC'ing tsv-area@ for some broader input. >=20 > (On first glance, the - user - privacy aspects here seem to be much = more contained, since ECN is mostly about the network exposing = information to the end systems, and not vice versa.) >=20 > Lars --Apple-Mail=_1F2F7D2B-855A-4955-93C0-24173DC72004 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAlod/rUACgkQihK3vwvq RqNFrg//ZL3OAGU/iG2WLs+ypl+vjoQafMC+dfgrfwphEDh9c50BzeB5+yrAy5vH HXgOS+yIZsHWer1o7BN0t6MPabWZgiw8jqs9t9BU1QW9+RI8K0zWdMgM7oqPKOoL SW8XzPXbwCEhHnuP2QJE+7P0HgK6RNpz8PZraZGhp/qsamEfCnl+OGhC+ALnN2cK mIcLlCVOfb+XiYA3JPTAsn2lni6Qw4kVmRQ943dmQoOwKvKEYeimC0pZla6MaciL 2UbRD/E/2SiEsP41vvBVCvhrfedZ/fV95IbR5mZ+0M9tOoZSUjSJyH5ZFG4ygTMN PABEDeIQIk6EQcFHTfATzDJsGdh7Xvyi6U8Ri7O0zh7O0XrlYCkR5/X09tOs706I SnFTYvsHqz2Ek4iKh4dLfFkRuvOk4w6DBpeapf4MZj70f2Ua1as1cK4sr2dpvAm6 NMYqUyIx7WUYjLPDLWS5gfk/VUVINKsG4rmdnj+CJhKo51/wM5qWPE8IdEQDlv6q T+3xCS2CYVU5v62pQCfzyT2dtZtBfzHLOJP7TlZf9e1HHu/EzI/iYLYhD2uBO++x jZlyqsmB+49NCGcu535TSIGlbUya7jy+ArNt2es5cRHMEDCUWqOCiT9PbRouYp1j QAxil2Ff+/oxkV+rzz1tkWGzhNXbr71iZUxx/m/7RO3RhaY6p8I= =7tZH -----END PGP SIGNATURE----- --Apple-Mail=_1F2F7D2B-855A-4955-93C0-24173DC72004-- From nobody Tue Nov 28 21:17:25 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71E8612025C for ; Tue, 28 Nov 2017 21:17:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se 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 c11AN_8fPC9i for ; Tue, 28 Nov 2017 21:17:22 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (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 631A31200F1 for ; Tue, 28 Nov 2017 21:17:22 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 00A94B1; Wed, 29 Nov 2017 06:17:19 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1511932640; bh=QlryJeUQPHmkcImmmdiqmCRcH0LD72+TNZkb2ZNpqi4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=lmoiY3EL4gAiYQiOMYjMBs9GwBMbJwKa8mGBcK0lXzFnij6jAJMpqfuPDUaUYmdAI UFY7UpVe02PQ+G67qoTtbxZfttiXwBf4mSdex9PHK59whUU3OGpeUMNJw4BqgtDKKu q410IUogVZG6U9+zjO7pvLyIMBnv1AXqFTyFcRj0= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id DD00FB0; Wed, 29 Nov 2017 06:17:19 +0100 (CET) Date: Wed, 29 Nov 2017 06:17:19 +0100 (CET) From: Mikael Abrahamsson To: Toerless Eckert cc: tsv-area@ietf.org Subject: Re: TCP behavior across WiFi pointers ? In-Reply-To: <20171108174247.GM19390@faui40p.informatik.uni-erlangen.de> Message-ID: References: <20171108174247.GM19390@faui40p.informatik.uni-erlangen.de> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 05:17:24 -0000 On Wed, 8 Nov 2017, Toerless Eckert wrote: > I am primarily thinking that there could be a higher demand for > TCP (end-to-end) retransmissions when using WiFi because the L2/WiFi > local retransmissions are insufficient. And if so, what the characteristics I don't know of any work you're asking for, but from my own experience radio networks (wifi + cellular) has the following (general) characteristics: They deliver packets in-order per host. The try very very hard to deliver all packets (true for unicast only on wifi), using L1/L2 retransmits. Because of this, they sometimes "stall" shorter or longer times, so you might get latency spikes of hundreds of milliseconds that are gone in the next second. My personal record is 180 SECONDS of RTT on a 2G network. These latency spikes might cause TCP to believe there was packet loss and cause retransmits, where there instead "only" was packet delay. Radio networks have airtime schedulers, so a single packet and a train of packets might have very different network experience. Some network types send multiple packets in a single transmit opportunity, and these transmit opportunities might be tens of milliseconds apart. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Nov 28 23:09:18 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45367124C27; Tue, 28 Nov 2017 23:09:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.com 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 p3gFini_j66F; Tue, 28 Nov 2017 23:09:09 -0800 (PST) Received: from mx142.netapp.com (mx142.netapp.com [IPv6:2620:10a:4005:8000:2306::b]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A364F124BAC; Tue, 28 Nov 2017 23:09:09 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.44,471,1505804400"; d="asc'?scan'208";a="225118421" Received: from vmwexchts04-prd.hq.netapp.com ([10.122.105.32]) by mx142-out.netapp.com with ESMTP; 28 Nov 2017 23:09:08 -0800 Received: from VMWEXCCAS05-PRD.hq.netapp.com (10.122.105.21) by VMWEXCHTS04-PRD.hq.netapp.com (10.122.105.32) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 28 Nov 2017 23:09:09 -0800 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS05-PRD.hq.netapp.com (10.122.105.21) with Microsoft SMTP Server (TLS) id 15.0.1320.4 via Frontend Transport; Tue, 28 Nov 2017 23:09:08 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9uw2E8SuM/7uen/f82zbL1YNl2gky+MDmEesKmvFKyE=; b=h/b8ke18wjC/btzLGplXbKKzMIhV6dge1btLfU8s8LsrL8hRH2xmCZVcYtwHNWhfU12DXGM+xzfu8etXTkb8MivifQKxY4dtbtBuybIlzW6cGdbkBGPRobs1VLFodzAi9V/LSqqgBuCff+fkHXCPMbphjG8hYrpz+PGrxD1+aVE= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.4; Wed, 29 Nov 2017 07:09:06 +0000 Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) by BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) with mapi id 15.20.0260.007; Wed, 29 Nov 2017 07:09:06 +0000 From: "Eggert, Lars" To: Brian Trammell CC: "Black, David" , "tsv-area@ietf.org" , QUIC WG , Al Morton Subject: Re: Spin bit discussion - where we're at Thread-Topic: Spin bit discussion - where we're at Thread-Index: AQHTY2jqp1VdukIM2U+G9HAjuBI8daMgHeUAgAANHICAAAmEgIAABm6AgAbXQwCAANXCAIACjivQgAAUcYCAAHB8gA== Date: Wed, 29 Nov 2017 07:09:06 +0000 Message-ID: References: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> <4D7F4AD313D3FC43A053B309F97543CF4904F2FD@njmtexg5.research.att.com> <791D0F33-4CB7-4049-AF29-174E41C1FD2E@netapp.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.4.7) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [109.43.1.141] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB1763; 6:qupB32bMn4CtHD+CY69E7Dn+zLFuCm6CAqDfcETKz/DT5arU6DUWLyASMg1kZt1ViXZJmm5y/yYmDCsVMa9ncRG60WaMmYkFdXkb5JuaPyt5DOSoCNg3mg8TFbKRFNEQs1C6dA/xFSZbcEVQkmQevQYp2UTKmHZjJyqMVYGELhLgbNPlCxU/Q5e/UCPGYDN2i+iuUVso8yxa8R6VWnE8+Na1Vgqg26lpWnqUoKlkqPZbPaZi0qQWiDVP9aSXJb7zJhVulCCr05Ck9DVygwp5outb5tun09YrW6hsH2223xdm9OWFFHRTnZcae3g1gm9pV/+0qp2ZNy54R5UHlZmvo/rUp6ZRZOpaciGImDG3Akk=; 5:FvvB9ktyxQHtH1HoPM/4S7Dua/5Y8yv0XGU0i4HpqIC9yBvH83OrvSV0/CZTvSJmn6U7z2JVAHWJA56xVKAYlwaZR7mdPXA1fz0QXVOzq98PbNYtrjXtT0Z8XQ8ygcR/FOFwmX14EsT7QA5km4smoiEdGK8eR2sqx7Wqb4xee74=; 24:FL2iQ/WWOjbFvi4qFGIZOJ18Wv+de6undAZ/Kq0IqKUhMJOC3OfkMUasJEyIOHo55BF65WNScoXbIiYRqrP21k+6qBJhf2GUlRWr0vz4QLI=; 7:VyhiF+X7Rr/QXp7+8DjsKzRr4Hugq6lk+C2wupRRgmk6qenYBphduAS3EczWIGsyitDRhMme5L/nny4YzfFd4sH3Y/FFnnlCilUZubTcQFFif37oddIWcoHZgHxPsB835WjwXXZHSyLQ5Qx+8SZkObAARJNigN1egLjDntuMOfEhFdY1bj7AfXzqMwjjmImKUXOgkaWydGUwcpOMxMh75HSek037eCRnAwVnKgm0915kUl69hSZnR3bEslnRNTea x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: e7b39c40-34ba-48c6-61d8-08d536f8146f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199)(49563074); SRVR:BLUPR06MB1763; x-ms-traffictypediagnostic: BLUPR06MB1763: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231022)(10201501046)(6055026)(6041248)(20161123558100)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(6072148)(201708071742011); SRVR:BLUPR06MB1763; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BLUPR06MB1763; x-forefront-prvs: 05066DEDBB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(366004)(346002)(376002)(24454002)(199003)(377424004)(189002)(86362001)(575784001)(99286004)(6246003)(8666007)(8936002)(99936001)(6512007)(68736007)(57306001)(14454004)(50226002)(54906003)(53936002)(6116002)(3280700002)(3846002)(229853002)(50986999)(4001150100001)(76176999)(4326008)(6506006)(102836003)(101416001)(478600001)(3660700001)(77096006)(6486002)(6436002)(97736004)(25786009)(2906002)(33656002)(106356001)(105586002)(189998001)(93886005)(305945005)(8676002)(7736002)(2900100001)(2950100002)(66066001)(83716003)(53546010)(316002)(36756003)(6916009)(5660300001)(81156014)(81166006)(82746002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB1763; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_B91C8370-C8A8-4F99-BE9F-A1C45F966D52"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e7b39c40-34ba-48c6-61d8-08d536f8146f X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Nov 2017 07:09:06.4332 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1763 X-OriginatorOrg: netapp.com Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 07:09:11 -0000 --Apple-Mail=_B91C8370-C8A8-4F99-BE9F-A1C45F966D52 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2017-11-29, at 1:26, Brian Trammell (IETF) wrote: > There are three possible states for an ECN negotiation: not attempted, = failed, and succeeded. Each of these can add a fractional bit of = information about the client and server TCP implementations. If a server = negotiates ECN, you can be reasonably certain that it supports ECN, and = can leverage the observations that sysadmins love defaults and servers = are mostly Linux these days to figure out whether it's running a kernel = before or after server side defaults were turned on. >=20 > Long-term observation of the ECN negotiation attempts of a client can = be used to determine if the client is using probabilistic negotiation by = default; i.e. is an Apple device of a certain vintage. >=20 > These are fractional bits of fingerprinting information, though, if = that. I'm almost certain (but won't take the time to do the research = now) that any of these observations would be useless. Anyone in a = position to make them could also get much more information about the = behavior of the TCP stacks at each end, such that the ECN bits add = negligible information. cf. p0f, if that's still a thing. this is certainly all true for TCP and ECN, where whether ECN is = available and/or tried by default is tied to a certain kernel versions. But for QUIC (=3D ECN with UDP), whether ECN is used or not is = completely up to the app (=3D the QUIC stack), so you can't draw = conclusions about whether a certain kernel or OS flavor is underneath = (other than they less than about ten years old, i.e., have support for = the IP_TOS/IP_RECVTOS socket options.) So the fractional information leakage seems to be less than with TCP. Lars --Apple-Mail=_B91C8370-C8A8-4F99-BE9F-A1C45F966D52 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAloeXREACgkQVLXDCb9w wVc+ihAAjiXHseS6HQXZjBeI4WAW4GzoJIo9K1DR68xMsFovTn+36OFh9qfc3gg4 ueAE9IozeqFzhKpawNYhuvcF0nAqngSKTIwXR4pR2fTx+Yhu0aHlONDdiwnhY7Xu tnjO00dIkUylyIBulH/hFncXxwZr1/wAAILCpKTxTKhy3btZYB1UpUqIBh5r2L3s A2KPe0wXdEGHXJp3QMTi3pDUvL66L1mP2dXu7D/7/J09PM/VSrjhyYbo5kcvlS3m t+Rowi8hI7TIr/9+T/dcxLXwu7Bm4M/zZ1yrNpVarcMi815kcISaHRLSvlCi2ngO mZhzczffdig4zeODMM99633t1pIBIuR/NqISxmOkgXF48SSQxwDGOH82vp5zr6EJ DgO6NW8V4GHzVvJDeV08oQZFkewZdMpI+kSGd8RMRnoOkGGtQBUQuKAPg5KRu6vc +v0LlCLd896ZSnqL3M2XvkYl68UuX7K932CSVmHGiG9DH9QR6FBqnpWMGYBIcyJx ymxDJx2bo4Z5s9VM34X1dTqlb4oAQtkLtacTcnvOBC00gtaVmHwdrcfaG4QC/ipk to0qbFLNn2u8mEl0qxWUfFAP/ycW7Tcog8Wl3sItB1U7sQp1kNJv6SdV3xp6bJdi bT+GGbZh+sVB2WNyARvZfxpk2m49MVa03gVMbUASIJsILV8EjfA= =Rl10 -----END PGP SIGNATURE----- --Apple-Mail=_B91C8370-C8A8-4F99-BE9F-A1C45F966D52-- From nobody Wed Nov 29 07:17:55 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F12A124B18 for ; Wed, 29 Nov 2017 07:17:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Zo800A8Us-aD for ; Wed, 29 Nov 2017 07:17:49 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45B9A1275C5 for ; Wed, 29 Nov 2017 07:17:49 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id t8so6974771wmc.3 for ; Wed, 29 Nov 2017 07:17:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/v8JQ+cDlxP1A0SQgSkgrEqFtLbZwUIzp5zXCF+Qjuo=; b=VMvjDHmPnEiP6cfT6/X3wpCPdKSNvqJ5vUwN9dRbtHXfu+gHGx4goFhlYxWJg8c5RC Z+khQY3RgY8odhiROaZ3gprcfkYrPUwGfaSm5d7BPu7rFqHw+nGe/TOiDrUDL1+ugaiD X16TTr8xODJtIbqr3p+3BHGWluj7Qw2NyG7apDHJ336EVEZSDQVJ/pg+dzeVRnMOt1Bq HE24HJ0YMZrne/naBrXEEH4mLpslmVv9t8uC+9as3/ep4aGeynZcz8mk1jEsqS365EaV xcnUwBz/ge4vwdFDYtakD1X8m7SIS2PIrjjMWsLMYELWM767nMQBeJPSnv4JIiPEC6PH 6SHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/v8JQ+cDlxP1A0SQgSkgrEqFtLbZwUIzp5zXCF+Qjuo=; b=Vb5DqMAYwlGy4KLf3FFvnfMP895H83eiK8/CLgTxjp7M0Nx7YQTtsrfauen+mWSIF/ 2hmwwuqjxkcg2vdBh3nJ0YNYSsjg6TFRHRxWQTTlvYVEucszziliEU8Zj2S6lYSl+USz CWNgNIVkQJ3n4GU6Xiunu6wjL4WfaYhsYAJt96mFfanW5R1IswsO7z0wz13dv7W/KmAD eF2MvZq/fHluE3NHWaMaIp05yzDqUGYWi5zIJHre95+DMF/rEnhH+khRiUg4BxTTdT2x hdWIZGPyIxkFyVlZqnWh7zAjxI54YIW5vc5rtLoE8ip3D/+QRBfxeGDmVkb6oUI/3WT0 v3kw== X-Gm-Message-State: AJaThX6we3IHlcKuR0+I0Z8RLenJM1zNJv9ejQdYMvGFeml47VuP0Xlx yEDtP3ppdHqqwf6B6YHOUGdjlV08YwGQcoJynSc= X-Google-Smtp-Source: AGs4zMbKYZpn/0SmrLOVrFoj7DG3pFzBjpfDMxWbg5JctBJOH9/kSztGKqCG1yqujoU8hLk28IznFEMBHdwX1g1+YBY= X-Received: by 10.80.180.18 with SMTP id b18mr8308213edh.136.1511968666765; Wed, 29 Nov 2017 07:17:46 -0800 (PST) MIME-Version: 1.0 References: <20171108174247.GM19390@faui40p.informatik.uni-erlangen.de> In-Reply-To: From: Aaron Falk Date: Wed, 29 Nov 2017 15:17:35 +0000 Message-ID: Subject: Re: TCP behavior across WiFi pointers ? To: Mark Allman Cc: Toerless Eckert , Michael Welzl , iccrg@irtf.org, tsv-area@ietf.org Content-Type: multipart/alternative; boundary="94eb2c1b58c64b4fca055f20a336" Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 15:17:50 -0000 --94eb2c1b58c64b4fca055f20a336 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey Mark- Didn't you do some work on TCP over wifi a while ago? --aaron On Wed, Nov 8, 2017 at 1:33 PM Michael Welzl wrote: > I would think that 1) there are probably pointers, and 2) the people who > have them should be on the ICCRG list, which I=E2=80=99m cc=E2=80=99ing. > > I suggest for this to be the last email that includes tsvarea so that the > thread entirely moves to ICCRG. > > > > On Nov 8, 2017, at 6:42 PM, Toerless Eckert wrote: > > > > Any pointers to work analyzing the differences in behavior when TCP is > run > > across WiFi as opposed to wired ? Especially with WiFi in the home ? > > > > I am primarily thinking that there could be a higher demand for > > TCP (end-to-end) retransmissions when using WiFi because the L2/WiFi > > local retransmissions are insufficient. And if so, what the > characteristics > > of those end-to-end retransmissions is (would assume they would be larg= er > > than N msec, where N is whatever the L2/wifi protection window is, whic= h > > unfortunately i don't know). > > > > Asking because we've got the poor "must-sit-in-back-of-the-bus" traffic > > called IP multicast that is not protected by L2/wifi retransmissions at > > all and now we're wondering if carrying it over TCP as a workaround > > could help, and therefore trying to educate myself on specific known > > issue left when running traffic over TCP over WiFi. > > > > If any other TSV or other WG mailing list might be a better place to > > ask. pls. let me know. > > > > Thank! > > Toerless > > > > --94eb2c1b58c64b4fca055f20a336 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Mark-

Didn't you do some work o= n TCP over wifi a while ago?

--aaron

On Wed, Nov 8, 2017 at 1:33 PM Michae= l Welzl <michawe@ifi.uio.no>= ; wrote:
I would think that 1) ther= e are probably pointers, and 2) the people who have them should be on the I= CCRG list, which I=E2=80=99m cc=E2=80=99ing.

I suggest for this to be the last email that includes tsvarea so that the t= hread entirely moves to ICCRG.


> On Nov 8, 2017, at 6:42 PM, Toerless Eckert <tte+ietf@cs.fau.de> wrote:
>
> Any pointers to work analyzing the differences in behavior when TCP is= run
> across WiFi as opposed to wired ? Especially with WiFi in the home ? >
> I am primarily thinking that there could be a higher demand for
> TCP (end-to-end) retransmissions when using WiFi because the L2/WiFi > local retransmissions are insufficient. And if so, what the characteri= stics
> of those end-to-end retransmissions is (would assume they would be lar= ger
> than N msec, where N is whatever the L2/wifi protection window is, whi= ch
> unfortunately i don't know).
>
> Asking because we've got the poor "must-sit-in-back-of-the-bu= s" traffic
> called IP multicast that is not protected by L2/wifi retransmissions a= t
> all and now we're wondering if carrying it over TCP as a workaroun= d
> could help, and therefore trying to educate myself on specific known > issue left when running traffic over TCP over WiFi.
>
> If any other TSV or other WG mailing list might be a better place to > ask. pls. let me know.
>
> Thank!
>=C2=A0 =C2=A0 Toerless
>

--94eb2c1b58c64b4fca055f20a336-- From nobody Wed Nov 29 13:59:17 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 263C3124BE8 for ; Wed, 29 Nov 2017 13:59:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 CDn9sdaGsb8I for ; Wed, 29 Nov 2017 13:59:11 -0800 (PST) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D99CD124205 for ; Wed, 29 Nov 2017 13:59:10 -0800 (PST) Received: by mail-wr0-x236.google.com with SMTP id a41so2934648wra.6 for ; Wed, 29 Nov 2017 13:59:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0dUpS7gRB65CemhHbaPDHOi7fXUP9C6XMu6daQoWIIw=; b=XHDaKYfBqj9r7LoRL3qeyQtZDWqiX/6HnDv/hCOR+S6DH/6/rwy/14qmXTPnmLUBJP sIWqGCKesL5NpeeyjQKMJ9D146iFOxTclipqnfSpvTrDmmiaYYtyifEOWdS+jX2oRiKc AtUBIwOp9rxA0nMB+gQ1IurG0HUZZItxpmHfqVeHun/DmPs6IPo70t5zuw+y9SXQRy36 SqObFUqCOmF61t72lLB/CF6awo11Yka4Do9px52n2GwmkOhHjCWNXlO60b2NB2wuUlZk 0vPgr3BNzW3znD/PN25YOH4ZfPyEYWOigxKDXe7nbMeElcLgB8vK5dnMem02gYNwWA67 TZOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0dUpS7gRB65CemhHbaPDHOi7fXUP9C6XMu6daQoWIIw=; b=Wl6Xr09zh7Tobu7slmAVP1StMoWb1OOV9bD6UNb1nTv+NTGi6h5KHgIWQPtD51lmhF 5hqhQdySfV6YiWQoSJdhG/hsqRKx3vUun0yfSwGppTdD4IEnf8pX0OIpfrjFa5Mju/qQ 9cq66C44hvyuoYg5FcNLM3J9LXpkWYFn1Z5XOL+vmBna9Z1+CCdNix45S6jJmjAGezFu 5OaJ+GvOQmNRTjHYndpDBFVEkyub5bNdKB5U7BZjgZrw77G92MxqqwPmObdlg5T8x6nQ bzBf5yTCOcIuzhN622PWAaJ68VlOz2O5L1R5LPAZKW05/rjtMd9ECRYXyqE3uhrdr+it qgpQ== X-Gm-Message-State: AJaThX4ikw5UQ2rZd8QqELkK/HuViVZSO0+48uFd4TcwlReV6/LMPt/a r2muttZQnr7Xg+NAnxd/IIuPwSous3Q997KtD+cR5Q== X-Google-Smtp-Source: AGs4zMaOPCcbdr6SJhVte3KG2QF7GkM02qkdFmqAncO4FRZnGje8Q8gc7LWb0qdupYXG5LQwbPBm7sqLqvPQloRljr8= X-Received: by 10.223.131.166 with SMTP id 35mr251733wre.84.1511992748841; Wed, 29 Nov 2017 13:59:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.16.10 with HTTP; Wed, 29 Nov 2017 13:58:28 -0800 (PST) In-Reply-To: References: <20171108174247.GM19390@faui40p.informatik.uni-erlangen.de> From: Yuchung Cheng Date: Wed, 29 Nov 2017 13:58:28 -0800 Message-ID: Subject: Re: TCP behavior across WiFi pointers ? To: Mikael Abrahamsson Cc: Toerless Eckert , "tsv-area@ietf.org >> tsv-area@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0df0dab335e6055f263ea1" Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 21:59:16 -0000 --94eb2c0df0dab335e6055f263ea1 Content-Type: text/plain; charset="UTF-8" On Tue, Nov 28, 2017 at 9:17 PM, Mikael Abrahamsson wrote: > On Wed, 8 Nov 2017, Toerless Eckert wrote: > > I am primarily thinking that there could be a higher demand for >> TCP (end-to-end) retransmissions when using WiFi because the L2/WiFi >> local retransmissions are insufficient. And if so, what the >> characteristics >> > > I don't know of any work you're asking for, but from my own experience > radio networks (wifi + cellular) has the following (general) > characteristics: > > They deliver packets in-order per host. > My experience is different. It is more similar to this post https://www.ietf.org/mail-archive/web/rmcat/current/msg00815.html > > The try very very hard to deliver all packets (true for unicast only on > wifi), using L1/L2 retransmits. > > Because of this, they sometimes "stall" shorter or longer times, so you > might get latency spikes of hundreds of milliseconds that are gone in the > next second. My personal record is 180 SECONDS of RTT on a 2G network. > > These latency spikes might cause TCP to believe there was packet loss and > cause retransmits, where there instead "only" was packet delay. > > Radio networks have airtime schedulers, so a single packet and a train of > packets might have very different network experience. Some network types > send multiple packets in a single transmit opportunity, and these transmit > opportunities might be tens of milliseconds apart. > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > > --94eb2c0df0dab335e6055f263ea1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Nov 28, 2017 at 9:17 PM, Mikael Abrahamsson &= lt;swmike@swm.pp.se> wrote:
<= span class=3D"gmail-">On Wed, 8 Nov 2017, Toerless Eckert wrote:

I am primarily thinking that there could be a higher demand for
TCP (end-to-end) retransmissions when using WiFi because the L2/WiFi
local retransmissions are insufficient. And if so, what the characteristics=

I don't know of any work you're asking for, but from my own experie= nce radio networks (wifi + cellular) has the following (general) characteri= stics:

They deliver packets in-order per host.
My experience = is different. It is more similar to this post

=C2=A0

The try very very hard to deliver all packets (true for unicast only on wif= i), using L1/L2 retransmits.

Because of this, they sometimes "stall" shorter or longer times, = so you might get latency spikes of hundreds of milliseconds that are gone i= n the next second. My personal record is 180 SECONDS of RTT on a 2G network= .

These latency spikes might cause TCP to believe there was packet loss and c= ause retransmits, where there instead "only" was packet delay.
Radio networks have airtime schedulers, so a single packet and a train of p= ackets might have very different network experience. Some network types sen= d multiple packets in a single transmit opportunity, and these transmit opp= ortunities might be tens of milliseconds apart.

--
Mikael Abrahamsson=C2=A0 =C2=A0 email: swmike@swm.pp.se


--94eb2c0df0dab335e6055f263ea1--