From nobody Thu Mar 2 06:12:02 2017 Return-Path: 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 C5C6B1295E5 for ; Thu, 2 Mar 2017 06:12:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 NjcWGczWKY5o for ; Thu, 2 Mar 2017 06:11:59 -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 3BD691295D0 for ; Thu, 2 Mar 2017 06:11:58 -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 1cjRSW-000B5H-Il for taps@ietf.org; Thu, 02 Mar 2017 15:11:56 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx04.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cjRSV-000CiW-UE; Thu, 02 Mar 2017 15:11:56 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: Date: Thu, 2 Mar 2017 15:11:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <32A3B146-09A8-4DB3-B3E3-58C5CD023625@ifi.uio.no> References: To: Aaron Falk X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx04.uio.no: 129.240.68.135 is neither permitted nor denied by domain of ifi.uio.no) client-ip=129.240.68.135; envelope-from=michawe@ifi.uio.no; helo=boomerang.ifi.uio.no; X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 6 sum msgs/h 3 total rcpts 52301 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-4.6, required=5.0, autolearn=disabled, AWL=0.404, RP_MATCHES_RCVD=-0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 8AACA744AC3212645F1A62C9BEA799476C98B12C X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -45 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 12471 max/h 21 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] agenda planning for chicago X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 14:12:01 -0000 Hi, We can't try to solve all the world's problems in one meeting. So I = suggest a more easily resolvable one: early data transmission (TFO, = ..). I could volunteer to lead this discussion; I have a feeling that Tommy = might also want to volunteer, in which case I'd happily let him take the = lead. Cheers, Michael > On 28 Feb 2017, at 16:24, Aaron Falk wrote: >=20 > Summarizing the agenda proposals. Did I miss anything? Names ok? Note = we need a leader for message sizes=E2=80=A6 >=20 > =E2=80=94aaron >=20 > Working group document updates >=20 > =E2=80=A2 draft-ietf-taps-transports-usage-03 (to be submitted): = 10-15 mins if possible, Naeem Khademi or myself > =E2=80=A2 draft-gjessing-taps-minset-04 (to be submitted): 10-15 = mins if possible, Stein Gjessing > TAPS Design Discussions >=20 > =E2=80=A2 Messaging, introduced by Michael Welzl > =E2=80=A2 Multi-streaming, introduced by Tommy Pauly > =E2=80=A2 message sizes & PMTU, introduced by ??? > Related Projects >=20 > =E2=80=A2 Happy Eyeballs, Anna Brunstrom > =E2=80=A2 NEAT, Naeem Khademi &/or Michael Welzl > =E2=80=A2 Post-Sockets, Tommy Pauly &/or Brian Trammel (remote) > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Fri Mar 3 07:42:01 2017 Return-Path: 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 B0FD01298C5 for ; Fri, 3 Mar 2017 07:41:59 -0800 (PST) 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 0plirHnGXS8w for ; Fri, 3 Mar 2017 07:41:58 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 247981298BF for ; Fri, 3 Mar 2017 07:41:58 -0800 (PST) Received: by mail-qk0-x22c.google.com with SMTP id 1so62343290qkl.3 for ; Fri, 03 Mar 2017 07:41:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=uKy1f3Vsa7YdtmN89SjaFC3lIM2SeBo/vMYaEHfL47I=; b=U3akNkorSUuYrD2le58c1fxvHNlsTpENHlEfMPsVImSWeEBS9dpheux4v5zwYGPMX+ XeJKi2j61aEqpuTCzfuMfKGacnZL1u5OMKSLwUwNI655TnsJa3KIZlUkSVz1rgVeUlUH MNBWp2zjYD3CL1R5yA5DPvjUgJ+sj1Q80C8oa6bxB3EvCQns3OcInK18yeGkKkhs4MFn yVmfsZeIbr40br2vnqmHSJZIi1LTGJhtpQEoD7SDDhxe75Hd0BcV/cYf0df/fR1WThFR eJedJDzqev4oLe8oI8B0v+QBMKyiEzeB1NH4dyO+t5fRBhi3F2imUWCMeh4HISfSJdvw pVpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=uKy1f3Vsa7YdtmN89SjaFC3lIM2SeBo/vMYaEHfL47I=; b=pHpLBgCPW22pAnUhgl5wPN34PKemqBLSVm3UbpSKRQOzbjbeu+HXc6eMBGDyQiiM31 IGHkCX5379w1mG0hWME+3c2jYQyIEcvsGGVNPciuibjqZzYDJfB6yGPNBGDrK/EQ0HKa k9LLi2IMVoE7fNy4Ul1zRuyKRFfxlXCkfG5mSjx7x2Ri10K9or7Ct4cjk/pKZfFHaymA mw4dnNWem0eDha1S02+B9JuRmx6SIfVLvZ6XMy8hmTM84UQ8YgqHG3gE0sRXRZrpdnLD QeeppmtMD3K+XR2ygaRM2w/dl6cOaDnHlworDQuAVy92+rBNY2f/vVb5ZyiCjxMTkxs5 DTvw== X-Gm-Message-State: AMke39m9Yc6aTQ/Sg/FCdL8Ubgr6rCOysj0l9bKaf6MUKZBxismzL5yivPr2iqq7o9sc5A== X-Received: by 10.200.44.235 with SMTP id 40mr3335935qtx.178.1488555717218; Fri, 03 Mar 2017 07:41:57 -0800 (PST) Received: from [172.19.36.87] ([2001:4878:8000:60:482c:47b0:901f:c379]) by smtp.gmail.com with ESMTPSA id t25sm7746557qkl.29.2017.03.03.07.41.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Mar 2017 07:41:56 -0800 (PST) From: "Aaron Falk" To: "Michael Welzl" Date: Fri, 03 Mar 2017 10:41:55 -0500 Message-ID: <650AA369-D81E-4AE3-9B3B-32AED194EDD6@gmail.com> In-Reply-To: <32A3B146-09A8-4DB3-B3E3-58C5CD023625@ifi.uio.no> References: <32A3B146-09A8-4DB3-B3E3-58C5CD023625@ifi.uio.no> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_4E37DE96-7375-4D6C-B122-1FEE7BAF45D3_=" Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5356) Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] agenda planning for chicago X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 15:41:59 -0000 --=_MailMate_4E37DE96-7375-4D6C-B122-1FEE7BAF45D3_= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sounds good to me. I’ll put you down as presenter and if Tommy wants in you guys can work it out. We have two hours so here’s the current agenda with times. I assume the time will split evenly within topics but you all can work out alternatives if you like. Seem reasonable? Any tweaks? —aaron - - - - # TAPS DRAFT AGENDA ## Administrivia and Chair’s Blah-blah - 10 min ## Working group document updates - 20 min * draft-ietf-taps-transports-usage-03, Naeem Khademi or Michael Welzl * draft-gjessing-taps-minset-04, Stein Gjessing ## TAPS Design Discussions - 60 min * Messaging, introduced by Michael Welzl * Multi-streaming, introduced by Tommy Pauly * Early data transmission, introduced by Michael Welzl ## Related Projects - 30 min * Happy Eyeballs, Anna Brunstrom * NEAT, Naeem Khademi &/or Michael Welzl * Post-Sockets, Tommy Pauly &/or Brian Trammel (remote) _______________________________________________ On 2 Mar 2017, at 9:11, Michael Welzl wrote: > Hi, > > We can't try to solve all the world's problems in one meeting. So I > suggest a more easily resolvable one: early data transmission (TFO, > ..). > > I could volunteer to lead this discussion; I have a feeling that Tommy > might also want to volunteer, in which case I'd happily let him take > the lead. > > Cheers, > Michael > > >> On 28 Feb 2017, at 16:24, Aaron Falk wrote: >> >> Summarizing the agenda proposals. Did I miss anything? Names ok? Note >> we need a leader for message sizes… >> >> —aaron >> >> Working group document updates >> >> • draft-ietf-taps-transports-usage-03 (to be submitted): 10-15 >> mins if possible, Naeem Khademi or myself >> • draft-gjessing-taps-minset-04 (to be submitted): 10-15 mins if >> possible, Stein Gjessing >> TAPS Design Discussions >> >> • Messaging, introduced by Michael Welzl >> • Multi-streaming, introduced by Tommy Pauly >> • message sizes & PMTU, introduced by ??? >> Related Projects >> >> • Happy Eyeballs, Anna Brunstrom >> • NEAT, Naeem Khademi &/or Michael Welzl >> • Post-Sockets, Tommy Pauly &/or Brian Trammel (remote) >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps --=_MailMate_4E37DE96-7375-4D6C-B122-1FEE7BAF45D3_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Sounds good to me. I=E2=80=99ll put you down as presente= r and if Tommy wants in you guys can work it out. We have two hours so h= ere=E2=80=99s the current agenda with times. I assume the time will spli= t evenly within topics but you all can work out alternatives if you like.= Seem reasonable? Any tweaks?

=E2=80=94aaron

TAPS DRAFT AGENDA

Administrivia and Chair=E2=80=99s Blah-blah= - 10 min

Working group document updates - 20 min
  • draft-ietf-taps-transports-usage-03, Naeem Khademi or Michael Welzl
  • draft-gjessing-taps-minset-04, Stein Gjessing

TAPS Design Discussions - 60 min

  • Messaging, introduced by Michael Welzl
  • Multi-streaming, introduced by Tommy Pauly
  • Early data transmission, introduced by Michael Welzl

Related Projects - 30 min

  • Happy Eyeballs, Anna Brunstrom
  • NEAT, Naeem Khademi &/or Michael Welzl
  • Post-Sockets, Tommy Pauly &/or Brian Trammel (remote)

On 2 Mar 2017, at 9:11, Michael Welzl wrote:

H= i,

We can't try to solve all the world's problems in one meeting. So I sugge= st a more easily resolvable one: early data transmission (TFO, ..).

I could volunteer to lead this discussion; I have a feeling that Tommy mi= ght also want to volunteer, in which case I'd happily let him take the le= ad.

Cheers,
Michael

On 28 Feb 2= 017, at 16:24, Aaron Falk <aaron.falk@gmail.com> wrote:

Summarizing the agenda proposals. Did I miss anything? Names ok? Note we = need a leader for message sizes=E2=80=A6

=E2=80=94aaron

Working group document updates

=E2=80=A2 draft-ietf-taps-transports-usage-03 (to be submitted): 10-15 m= ins if possible, Naeem Khademi or myself
=E2=80=A2 draft-gjessing-taps-minset-04 (to be submitted): 10-15 mins if= possible, Stein Gjessing
TAPS Design Discussions

=E2=80=A2 Messaging, introduced by Michael Welzl
=E2=80=A2 Multi-streaming, introduced by Tommy Pauly
=E2=80=A2 message sizes & PMTU, introduced by ???
Related Projects

=E2=80=A2 Happy Eyeballs, Anna Brunstrom
=E2=80=A2 NEAT, Naeem Khademi &/or Michael Welzl
=E2=80=A2 Post-Sockets, Tommy Pauly &/or Brian Trammel (remote)
_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

--=_MailMate_4E37DE96-7375-4D6C-B122-1FEE7BAF45D3_=-- From nobody Fri Mar 3 07:48:09 2017 Return-Path: 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 0BFA612946D for ; Fri, 3 Mar 2017 07:48:08 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 fUoeSJBGrRx5 for ; Fri, 3 Mar 2017 07:48:05 -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 9F02A1294B4 for ; Fri, 3 Mar 2017 07:48:05 -0800 (PST) Received: from mail-mx05.uio.no ([129.240.10.49]) by mail-out02.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cjpR5-00056Y-BK for taps@ietf.org; Fri, 03 Mar 2017 16:48:03 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx05.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cjpR4-000FDA-Rw; Fri, 03 Mar 2017 16:48:03 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: <650AA369-D81E-4AE3-9B3B-32AED194EDD6@gmail.com> Date: Fri, 3 Mar 2017 16:48:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <129CFBE5-E67D-4C85-9FAD-59C90F860FB8@ifi.uio.no> References: <32A3B146-09A8-4DB3-B3E3-58C5CD023625@ifi.uio.no> <650AA369-D81E-4AE3-9B3B-32AED194EDD6@gmail.com> To: Aaron Falk X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx05.uio.no: 129.240.68.135 is neither permitted nor denied by domain of ifi.uio.no) client-ip=129.240.68.135; envelope-from=michawe@ifi.uio.no; helo=boomerang.ifi.uio.no; X-UiO-Ratelimit-Test: rcpts/h 7 msgs/h 2 sum rcpts/h 8 sum msgs/h 2 total rcpts 52351 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.031, RP_MATCHES_RCVD=-0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: C87950C0F66DD029E1F93A8EE063FC2BEC19DC63 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 12492 max/h 21 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] agenda planning for chicago X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 15:48:08 -0000 looks good to me... > On 03 Mar 2017, at 16:41, Aaron Falk wrote: >=20 > Sounds good to me. I=E2=80=99ll put you down as presenter and if Tommy = wants in you guys can work it out. We have two hours so here=E2=80=99s = the current agenda with times. I assume the time will split evenly = within topics but you all can work out alternatives if you like. Seem = reasonable? Any tweaks? >=20 > =E2=80=94aaron >=20 > TAPS DRAFT AGENDA >=20 > Administrivia and Chair=E2=80=99s Blah-blah - 10 min >=20 > Working group document updates - 20 min >=20 > =E2=80=A2 draft-ietf-taps-transports-usage-03, Naeem Khademi or = Michael Welzl > =E2=80=A2 draft-gjessing-taps-minset-04, Stein Gjessing > TAPS Design Discussions - 60 min >=20 > =E2=80=A2 Messaging, introduced by Michael Welzl > =E2=80=A2 Multi-streaming, introduced by Tommy Pauly > =E2=80=A2 Early data transmission, introduced by Michael Welzl > Related Projects - 30 min >=20 > =E2=80=A2 Happy Eyeballs, Anna Brunstrom > =E2=80=A2 NEAT, Naeem Khademi &/or Michael Welzl > =E2=80=A2 Post-Sockets, Tommy Pauly &/or Brian Trammel (remote) > On 2 Mar 2017, at 9:11, Michael Welzl wrote: >=20 >=20 > Hi, >=20 > We can't try to solve all the world's problems in one meeting. So I = suggest a more easily resolvable one: early data transmission (TFO, ..). >=20 > I could volunteer to lead this discussion; I have a feeling that Tommy = might also want to volunteer, in which case I'd happily let him take the = lead. >=20 > Cheers, > Michael >=20 > On 28 Feb 2017, at 16:24, Aaron Falk wrote: >=20 > Summarizing the agenda proposals. Did I miss anything? Names ok? Note = we need a leader for message sizes=E2=80=A6 >=20 > =E2=80=94aaron >=20 > Working group document updates >=20 > =E2=80=A2 draft-ietf-taps-transports-usage-03 (to be submitted): 10-15 = mins if possible, Naeem Khademi or myself > =E2=80=A2 draft-gjessing-taps-minset-04 (to be submitted): 10-15 mins = if possible, Stein Gjessing > TAPS Design Discussions >=20 > =E2=80=A2 Messaging, introduced by Michael Welzl > =E2=80=A2 Multi-streaming, introduced by Tommy Pauly > =E2=80=A2 message sizes & PMTU, introduced by ??? > Related Projects >=20 > =E2=80=A2 Happy Eyeballs, Anna Brunstrom > =E2=80=A2 NEAT, Naeem Khademi &/or Michael Welzl > =E2=80=A2 Post-Sockets, Tommy Pauly &/or Brian Trammel (remote) > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Fri Mar 3 16:01:53 2017 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 125F1129679; Fri, 3 Mar 2017 15:55:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148858533607.15846.10282931350298672105.idtracker@ietfa.amsl.com> Date: Fri, 03 Mar 2017 15:55:36 -0800 Archived-At: Cc: spencerdawkins.ietf@gmail.com, taps@ietf.org Subject: [Taps] taps - Requested session has been scheduled for IETF 98 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 23:55:36 -0000 Dear Aaron Falk, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. taps Session 1 (2:00:00) Tuesday, Afternoon Session III 1640-1840 Room Name: Zurich E/F size: 200 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Transport Services Area Name: Transport Area Session Requester: Aaron Falk Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: maprg dispatch tcpm iccrg tsvwg ippm rmcat aqm tsvarea appsawg apparea quic Second Priority: webpush tcpinc nvo3 mptcp icnrg httpbis irtfopen Third Priority: mmusic tram People who must be present: Aaron Falk Michael Welzl Gorry Fairhurst Spencer Dawkins Brian Trammell Zaheduzzaman Sarker Mirja Kuehlewind Resources Requested: Meetecho support in room Experimental room setup (boardroom and classroom) subject to availability Special Requests: Requesting U-shape room setup. Monday to Wednesday --------------------------------------------------------- From nobody Tue Mar 7 14:19:30 2017 Return-Path: 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 324E0129660; Tue, 7 Mar 2017 14:19:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 VEF0b17nHnZS; Tue, 7 Mar 2017 14:19:05 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72BDB129657; Tue, 7 Mar 2017 14:18:39 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 0675EB819B9; Tue, 7 Mar 2017 14:18:38 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20170307221838.0675EB819B9@rfc-editor.org> Date: Tue, 7 Mar 2017 14:18:38 -0800 (PST) Archived-At: Cc: drafts-update-ref@iana.org, taps@ietf.org, rfc-editor@rfc-editor.org Subject: [Taps] RFC 8095 on Services Provided by IETF Transport Protocols and Congestion Control Mechanisms X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 22:19:17 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8095 Title: Services Provided by IETF Transport Protocols and Congestion Control Mechanisms Author: G. Fairhurst, Ed., B. Trammell, Ed., M. Kuehlewind, Ed. Status: Informational Stream: IETF Date: March 2017 Mailbox: gorry@erg.abdn.ac.uk, ietf@trammell.ch, mirja.kuehlewind@tik.ee.ethz.ch Pages: 54 Characters: 126843 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-taps-transports-14.txt URL: https://www.rfc-editor.org/info/rfc8095 DOI: 10.17487/RFC8095 This document describes, surveys, and classifies the protocol mechanisms provided by existing IETF protocols, as background for determining a common set of transport services. It examines the Transmission Control Protocol (TCP), Multipath TCP, the Stream Control Transmission Protocol (SCTP), the User Datagram Protocol (UDP), UDP-Lite, the Datagram Congestion Control Protocol (DCCP), the Internet Control Message Protocol (ICMP), the Real-Time Transport Protocol (RTP), File Delivery over Unidirectional Transport / Asynchronous Layered Coding (FLUTE/ALC) for Reliable Multicast, NACK- Oriented Reliable Multicast (NORM), Transport Layer Security (TLS), Datagram TLS (DTLS), and the Hypertext Transport Protocol (HTTP), when HTTP is used as a pseudotransport. This survey provides background for the definition of transport services within the TAPS working group. This document is a product of the Transport Services Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Tue Mar 7 14:23:03 2017 Return-Path: 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 39C7A129625 for ; Tue, 7 Mar 2017 14:23:01 -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, 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 jq3a5cyUFZSs for ; Tue, 7 Mar 2017 14:22:59 -0800 (PST) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::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 44ECB12961C for ; Tue, 7 Mar 2017 14:22:59 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id 1so29418966qkl.3 for ; Tue, 07 Mar 2017 14:22:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-transfer-encoding; bh=DbGzVRfoir25qunYwkDLJ4jl0ueV7mD/zkE2hqMOlaE=; b=S4BtnaCaMQ1dgned7Kf3wt2V/cFB08SXD8X4eKsY+GfKY/FyF7bUeHjTTFEKdAuGcp LAMd4Jp33boH+3wsuYM9KfB1GRYNarsa7aklapyKoIoZsp7VSYeSTPujlQro+J6wfA/v iwOYcL0HHm7AuJyYcH44yXvO7sRIgHKzWISY84znb1Ytk14dcSJ+ZmbBJ5mQkJQE929S R+77yJ46HAcxXqrQgAjlN4tNrUIVrVwcQKxuSJOBrWFT73oEH/mI6ORMz14zchFwrLT9 iP4rbvgGr8ulCXHU3rZqSjRivX785F3IqkWeWcPNKv4F4yDKFX0Sa6yzSqdl1R7gzzLd uR5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=DbGzVRfoir25qunYwkDLJ4jl0ueV7mD/zkE2hqMOlaE=; b=UsJ6kTQ9bdnR1QdL8cJwoXDZJL5yAlk2f267XOKsWrFPuxlF4Kno923YcOI4vl7NoO aqqC4QxSZS2dvJ13qXMAdJfXwoAMHaRpdq6PVHQBno9o0kq/SzvT7ds82n9nSMyvRnwB glPFCRAWPkKWjv8U5TQwWJPP/Wnq8JjIiYe3GzvVAiuC1zKjKGV8qDGVa7JRRFSXtwI0 WQDMa93+wEGMU5oL9q+OdalyPgz+s/abp6bdQ8np1FELRSi3voNn0uOtw1WeZsSEXvjU uoLq79V1mKbta+pP8HSeTphBt6Lne+OKE/giOs01hlp/BAfC90myMx3Rj3QtwHc633o6 Y2Jw== X-Gm-Message-State: AFeK/H0TkHAD3Vy+7cQqj/ON9pLsxkqzT7ehPfVQJCQxPjKx7ghK4nMxX4WR6N78dQkqYw== X-Received: by 10.55.94.6 with SMTP id s6mr3602213qkb.166.1488925378338; Tue, 07 Mar 2017 14:22:58 -0800 (PST) Received: from [172.19.33.209] ([2001:4878:8000:60:fda8:c06f:d163:83dd]) by smtp.gmail.com with ESMTPSA id m12sm883402qtm.45.2017.03.07.14.22.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Mar 2017 14:22:57 -0800 (PST) From: "Aaron Falk" To: "taps WG" , "Gorry Fairhurst" , "Brian Trammell" , "Mirja =?utf-8?q?K=C3=BChlewind?=" Date: Tue, 07 Mar 2017 17:22:57 -0500 Message-ID: In-Reply-To: <20170307221838.0675EB819B9@rfc-editor.org> References: <20170307221838.0675EB819B9@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5356) Archived-At: Subject: Re: [Taps] RFC 8095 on Services Provided by IETF Transport Protocols and Congestion Control Mechanisms X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 22:23:01 -0000 TAPS doc 1 published. Thank you, Brian, Mirja, & Gorry! —aaron On 7 Mar 2017, at 17:18, rfc-editor@rfc-editor.org wrote: > A new Request for Comments is now available in online RFC libraries. > > > RFC 8095 > > Title: Services Provided by IETF Transport > Protocols and Congestion Control Mechanisms > Author: G. Fairhurst, Ed., > B. Trammell, Ed., > M. Kuehlewind, Ed. > Status: Informational > Stream: IETF > Date: March 2017 > Mailbox: gorry@erg.abdn.ac.uk, > ietf@trammell.ch, > mirja.kuehlewind@tik.ee.ethz.ch > Pages: 54 > Characters: 126843 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-taps-transports-14.txt > > URL: https://www.rfc-editor.org/info/rfc8095 > > DOI: 10.17487/RFC8095 > > This document describes, surveys, and classifies the protocol > mechanisms provided by existing IETF protocols, as background for > determining a common set of transport services. It examines the > Transmission Control Protocol (TCP), Multipath TCP, the Stream > Control Transmission Protocol (SCTP), the User Datagram Protocol > (UDP), UDP-Lite, the Datagram Congestion Control Protocol (DCCP), the > Internet Control Message Protocol (ICMP), the Real-Time Transport > Protocol (RTP), File Delivery over Unidirectional Transport / > Asynchronous Layered Coding (FLUTE/ALC) for Reliable Multicast, NACK- > Oriented Reliable Multicast (NORM), Transport Layer Security (TLS), > Datagram TLS (DTLS), and the Hypertext Transport Protocol (HTTP), > when HTTP is used as a pseudotransport. This survey provides > background for the definition of transport services within the TAPS > working group. > > This document is a product of the Transport Services Working Group of > the IETF. > > > INFORMATIONAL: This memo provides information for the Internet > community. > It does not specify an Internet standard of any kind. Distribution of > this memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > https://www.ietf.org/mailman/listinfo/ietf-announce > https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see https://www.rfc-editor.org/search > For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. > Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > Association Management Solutions, LLC > > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Wed Mar 8 00:31:05 2017 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 45132127071; Wed, 8 Mar 2017 00:31:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148896186226.26267.9891445617205312227@ietfa.amsl.com> Date: Wed, 08 Mar 2017 00:31:02 -0800 Archived-At: Cc: taps@ietf.org Subject: [Taps] I-D Action: draft-ietf-taps-transports-usage-03.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 08:31:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Services of the IETF. Title : On the Usage of Transport Features Provided by IETF Transport Protocols Authors : Michael Welzl Michael Tuexen Naeem Khademi Filename : draft-ietf-taps-transports-usage-03.txt Pages : 48 Date : 2017-03-08 Abstract: This document describes how TCP, MPTCP, SCTP, UDP and UDP-Lite expose services to applications and how an application can configure and use the transport features that make up these services. It also discusses the service provided by the LEDBAT congestion control mechanism. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-taps-transports-usage/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-taps-transports-usage-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-usage-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Mar 8 00:36:23 2017 Return-Path: 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 44953129428 for ; Wed, 8 Mar 2017 00:36:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 zMzyYy4wPdM7 for ; Wed, 8 Mar 2017 00:36:17 -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 1A210127071 for ; Wed, 8 Mar 2017 00:36:17 -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 1clX4w-000FWi-OX for taps@ietf.org; Wed, 08 Mar 2017 09:36:14 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx04.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1clX4w-000GHT-18 for taps@ietf.org; Wed, 08 Mar 2017 09:36:14 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: <148896186226.26267.9891445617205312227@ietfa.amsl.com> Date: Wed, 8 Mar 2017 09:36:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148896186226.26267.9891445617205312227@ietfa.amsl.com> To: "taps@ietf.org" X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx04.uio.no: 129.240.68.135 is neither permitted nor denied by domain of ifi.uio.no) client-ip=129.240.68.135; envelope-from=michawe@ifi.uio.no; helo=boomerang.ifi.uio.no; X-UiO-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 5 sum msgs/h 4 total rcpts 52507 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-4.8, required=5.0, autolearn=disabled, AWL=0.193, RP_MATCHES_RCVD=-0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: ABD1498BB3AD29979128720B608539B1C36AF645 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -47 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 12545 max/h 21 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-usage-03.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 08:36:21 -0000 Dear all, This is a quite major update: from our (author's) point of view, it now = (at last!) captures all the RFC-defined API primitives / transport = features of TCP, MPTCP, SCTP, UDP(-Lite) and LEDBAT. So, if you want to check if we missed your favorite feature, that time = has come :-) Cheers, Michael > On 08 Mar 2017, at 09:31, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Transport Services of the IETF. >=20 > Title : On the Usage of Transport Features Provided = by IETF Transport Protocols > Authors : Michael Welzl > Michael Tuexen > Naeem Khademi > Filename : draft-ietf-taps-transports-usage-03.txt > Pages : 48 > Date : 2017-03-08 >=20 > Abstract: > This document describes how TCP, MPTCP, SCTP, UDP and UDP-Lite = expose > services to applications and how an application can configure and = use > the transport features that make up these services. It also > discusses the service provided by the LEDBAT congestion control > mechanism. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-taps-transports-usage/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-taps-transports-usage-03 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-taps-transports-usage-03 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Wed Mar 8 14:55:29 2017 Return-Path: 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 6AF741294F2 for ; Wed, 8 Mar 2017 14:55:28 -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, RCVD_IN_DNSWL_LOW=-0.7] 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 NKqhlHMV_USp for ; Wed, 8 Mar 2017 14:55:27 -0800 (PST) Received: from gozo.iway.ch (gozo.iway.ch [IPv6:2001:8e0:40:325::36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C64591294C9 for ; Wed, 8 Mar 2017 14:55:26 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 49C9E340E1C for ; Wed, 8 Mar 2017 23:55:25 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/22542.25521); Wed, 8 Mar 2017 23:55:25 +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 for ; Wed, 8 Mar 2017 23:55:25 +0100 (CET) Received: from [94.247.222.80] (account ietf@trammell.ch HELO [10.11.33.4]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.14) with ESMTPSA id 10854728 for taps@ietf.org; Wed, 08 Mar 2017 23:55:25 +0100 From: "Brian Trammell (IETF)" Content-Type: multipart/signed; boundary="Apple-Mail=_DA2939C5-0B12-46CC-A5B5-4635D129DB27"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: <47879123-53E9-46FD-822A-5F5111664C43@trammell.ch> Date: Wed, 8 Mar 2017 23:55:24 +0100 To: taps WG X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [Taps] draft-trammell-taps-post-sockets X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 22:55:28 -0000 --Apple-Mail=_DA2939C5-0B12-46CC-A5B5-4635D129DB27 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Greetings, all, As promised in Seoul, and a full five days ahead of deadline :) we=E2=80=99= ve posted a TAPS-named version of the Post Sockets draft: https://datatracker.ietf.org/doc/draft-trammell-taps-post-sockets/ This draft contains significant changes (the authors hope, improvements) = from the previous version, in large part taken from input at a meeting = held by the authors with a few invited contributors at ETH Zurich in = February. Cheers, Brian --Apple-Mail=_DA2939C5-0B12-46CC-A5B5-4635D129DB27 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----- iQIcBAEBCAAGBQJYwIvcAAoJEIoSt78L6kajpYEQAMZvIn+1/A3c9s8lkAw59ZFr sCtQYuvV4oZHBf16HDfHFYTvjOOhJz+op1T8qiGZjJEIcx0wX6UI5qPu5NEOK/KV gbBSlGOuZz8ERZedmMgc02xa84m1hHkZbJXZc2+t2RD32IFDvHUBj0xi72LYj6RI yb8ZzaCkskS7L03dTArxpxQiQ03qgGDp2OVW99Y0DpZEjt2w+RuIx6nPE4hhEL8h GnHhcX1Ou1YZfp9XlQelEa+WCd70CofaTFGPX5s/WgTKMgEe/EbMrQuIlArOCf1K e/CfrkJqh7puMsT5GQWF4pxub0CRQrlpP7HDRitQk7ulcEctjV2iBVDhnYY6wT6d 3KRxxo9/thWLW+QWhAQFNaNEzuZuHW2U/bdd5E6WT44IfoZ0p69o76WW/3ZZXFYa zxrpK1HtlHG4edFGJ2GddAE5zMyqswsEsE0P3IzWHm0+H41RtO6WvCWFFJRnmMY6 4IFEtnbb6skQlZWYiibBnhc6ZSb4xpOHoiv+l+rQiiK9CdPSZZJB/KE8RWJ+x1hk 8RGq+505AVTOnyLC3Lebcb+36U+VWBpFrljv1fw5+RknPTloEopbq5SP1D/QCjdw TN3T4ewIiICk8n1S1PdcMwR7mED9Qa+e5LmcxP8mlRUnrx1HFidypobGD10hOCMv KWwvChl+NSXq2ZIEd7dy =Mwqy -----END PGP SIGNATURE----- --Apple-Mail=_DA2939C5-0B12-46CC-A5B5-4635D129DB27-- From nobody Thu Mar 9 07:43:58 2017 Return-Path: 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 0FBB21294D8 for ; Thu, 9 Mar 2017 07:43:57 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 LBbJTIxWgVaF for ; Thu, 9 Mar 2017 07:43:54 -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 9EA841294E0 for ; Thu, 9 Mar 2017 07:43:54 -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 1cm0EJ-000CeY-PX for taps@ietf.org; Thu, 09 Mar 2017 16:43:51 +0100 Received: from 234.133.189.109.customer.cdi.no ([109.189.133.234] helo=[192.168.1.8]) 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 1cm0EI-000G5Q-EC for taps@ietf.org; Thu, 09 Mar 2017 16:43:51 +0100 From: Michael Welzl Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 9 Mar 2017 16:43:49 +0100 References: <148896186226.26267.9891445617205312227@ietfa.amsl.com> To: "taps@ietf.org" In-Reply-To: Message-Id: <1D4A0D56-6499-488C-9EE5-5CA33980B7E1@ifi.uio.no> X-Mailer: Apple Mail (2.3259) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx04.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.8]; X-UiO-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 6 sum msgs/h 5 total rcpts 52563 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.039, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: B50EF304A41CF5BF93A60591C6E833E56A60D82C X-UiO-SPAM-Test: remote_host: 109.189.133.234 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 968 max/h 13 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-usage-03.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 15:43:57 -0000 > On Mar 8, 2017, at 9:36 AM, Michael Welzl wrote: >=20 > Dear all, >=20 > This is a quite major update: from our (author's) point of view, it = now (at last!) captures all the RFC-defined API primitives / transport = features of TCP, MPTCP, SCTP, UDP(-Lite) and LEDBAT. Sigh, with one exception - I had a plan to include it but when I checked = again I overlooked section 7.1: TCP-AO (RFC 5925) requires some changes = to the TCP user interface, not covered in this document. That one will = go into the next update, together with any other suggestions we=E2=80=99ll= receive=E2=80=A6 Cheers, Michael >=20 > Cheers, > Michael >=20 >=20 >> On 08 Mar 2017, at 09:31, internet-drafts@ietf.org wrote: >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Transport Services of the IETF. >>=20 >> Title : On the Usage of Transport Features Provided = by IETF Transport Protocols >> Authors : Michael Welzl >> Michael Tuexen >> Naeem Khademi >> Filename : draft-ietf-taps-transports-usage-03.txt >> Pages : 48 >> Date : 2017-03-08 >>=20 >> Abstract: >> This document describes how TCP, MPTCP, SCTP, UDP and UDP-Lite = expose >> services to applications and how an application can configure and = use >> the transport features that make up these services. It also >> discusses the service provided by the LEDBAT congestion control >> mechanism. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-taps-transports-usage/ >>=20 >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-taps-transports-usage-03 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-taps-transports-usage-03= >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Mon Mar 13 09:06:24 2017 Return-Path: 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 01F00129428 for ; Mon, 13 Mar 2017 09:06:23 -0700 (PDT) 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 2YuJctAsGJhu for ; Mon, 13 Mar 2017 09:06:20 -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 6D55A129405 for ; Mon, 13 Mar 2017 09:06:20 -0700 (PDT) Received: from mail-mx03.uio.no ([129.240.10.15]) by mail-out02.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cnSUE-0006rN-RQ for taps@ietf.org; Mon, 13 Mar 2017 17:06:18 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx03.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cnSUD-000086-3c for taps@ietf.org; Mon, 13 Mar 2017 17:06:18 +0100 From: Michael Welzl Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Mar 2017 17:06:16 +0100 References: <148942050575.17043.6419886474129053646.idtracker@ietfa.amsl.com> To: taps WG Message-Id: Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx03.uio.no: 129.240.68.135 is neither permitted nor denied by domain of ifi.uio.no) client-ip=129.240.68.135; envelope-from=michawe@ifi.uio.no; helo=boomerang.ifi.uio.no; X-UiO-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 4 sum msgs/h 3 total rcpts 52629 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=-0.044, RP_MATCHES_RCVD=-0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 9628D46657F19F2B36B1D68694249908C82984B8 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 12574 max/h 21 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: [Taps] Fwd: New Version Notification for draft-gjessing-taps-minset-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 16:06:23 -0000 Dear TAPS WG, This update addresses the feedback that we got at the last meeting: = people said that this minset isn't much of a minset. ... that's because = we had only worked on the first step: categorizing transport features = such that the list can then be reduced. Now, in this update: - we've brought the list in line with the latest version of the -usage = draft (the list is a lot longer now, and includes what we think are = *all* transport features of TCP, MPTCP, SCTP, UDP(-Lite) ... except for = TCP Authentication. We'll fix this one in the next version. - we then shortened the list brutally :) by only allowing = "functional" and "optimizing" transport features, and also removing = transport features for which it doesn't seem possible to fall back to = TCP - we then wrote text discussing the strange list that we got ... some = weird things there need consideration when designing a TAPS system - and then we made a first stab at constructing a "minimum set", derived = from the above. I hope folks will find this interesting despite its length - it captures = several things that I've had in mind for a while, and partially talked = about to people, but never really wrote up anywhere. A lot of love has = gone into this document ;-) Cheers, Michael > Begin forwarded message: >=20 > From: > Subject: New Version Notification for = draft-gjessing-taps-minset-04.txt > Date: 13 Mar 2017 16:55:05 CET > To: Michael Welzl , Stein Gjessing = > Resent-From: >=20 >=20 > A new version of I-D, draft-gjessing-taps-minset-04.txt > has been successfully submitted by Michael Welzl and posted to the > IETF repository. >=20 > Name: draft-gjessing-taps-minset > Revision: 04 > Title: A Minimal Set of Transport Services for TAPS = Systems > Document date: 2017-03-13 > Group: Individual Submission > Pages: 38 > URL: = https://www.ietf.org/internet-drafts/draft-gjessing-taps-minset-04.txt > Status: = https://datatracker.ietf.org/doc/draft-gjessing-taps-minset/ > Htmlized: = https://tools.ietf.org/html/draft-gjessing-taps-minset-04 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-gjessing-taps-minset-04 >=20 > Abstract: > This draft recommends a minimal set of IETF Transport Services > offered by end systems supporting TAPS, and gives guidance on > choosing among the available mechanisms and protocols. It is based > on the set of transport features given in the TAPS document > draft-ietf-taps-transports-usage-03. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 From nobody Tue Mar 14 02:37:59 2017 Return-Path: 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 83EDA1293F9 for ; Tue, 14 Mar 2017 02:37:57 -0700 (PDT) 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, HTML_MESSAGE=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 GdtoaD4rJcLf for ; Tue, 14 Mar 2017 02:37:55 -0700 (PDT) Received: from tiger.dc.kau.se (smtp.kau.se [193.10.220.38]) (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 D3AEB127076 for ; Tue, 14 Mar 2017 02:37:54 -0700 (PDT) X-Spam-Processed: mail.kau.se, Tue, 14 Mar 2017 10:37:47 +0100 (not processed: spam filter heuristic analysis disabled) X-MDRemoteIP: 193.11.155.184 X-MDArrival-Date: Tue, 14 Mar 2017 10:37:47 +0100 X-Authenticated-Sender: anna.brunstrom@kau.se X-Return-Path: anna.brunstrom@kau.se X-Envelope-From: anna.brunstrom@kau.se X-MDaemon-Deliver-To: taps@ietf.org References: <148942913904.9187.9087920412455130356.idtracker@ietfa.amsl.com> To: "taps@ietf.org" From: Anna Brunstrom X-Forwarded-Message-Id: <148942913904.9187.9087920412455130356.idtracker@ietfa.amsl.com> Message-ID: <9fcb9fc9-4cd9-38e7-c51c-d376f01b933d@kau.se> Date: Tue, 14 Mar 2017 10:37:44 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <148942913904.9187.9087920412455130356.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------0AB3F9908729667D414BFF31" Archived-At: Subject: [Taps] Fwd: New Version Notification for draft-grinnemo-taps-he-02.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 09:37:57 -0000 This is a multi-part message in MIME format. --------------0AB3F9908729667D414BFF31 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi all, The draft below on happy eyeballs was submitted last night. It is on the agenda for Chicago, but we are happy to hear any comments you may have also before then. Cheers, Anna -------- Forwarded Message -------- Subject: New Version Notification for draft-grinnemo-taps-he-02.txt Date: Mon, 13 Mar 2017 11:18:59 -0700 From: internet-drafts@ietf.org To: Zdravko Bozakov , Zdravko Bozakov , Anna Brunstrom , Per Hurtig , Karl-Johan Grinnemo , Naeem Khademi A new version of I-D, draft-grinnemo-taps-he-02.txt has been successfully submitted by Karl-Johan Grinnemo and posted to the IETF repository. Name: draft-grinnemo-taps-he Revision: 02 Title: Happy Eyeballs for Transport Selection Document date: 2017-03-13 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/internet-drafts/draft-grinnemo-taps-he-02.txt Status: https://datatracker.ietf.org/doc/draft-grinnemo-taps-he/ Htmlized: https://tools.ietf.org/html/draft-grinnemo-taps-he-02 Diff: https://www.ietf.org/rfcdiff?url2=draft-grinnemo-taps-he-02 Abstract: Ideally, network applications should be able to select an appropriate transport solution from among available transport solutions. However, at present, there is no agreed-upon way to do this. In fact, there is not even an agreed-upon way for a source end host to determine if there is support for a particular transport along a network path. This draft addresses these issues, by proposing a Happy Eyeballs framework. The proposed Happy Eyeballs framework enables the selection of a transport solution that according to application requirements, pre-set policies, and estimated network conditions is the most appropriate one. Additionally, the proposed framework makes it possible for an application to find out whether a particular transport is supported along a network connection towards a specific destination or not. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------0AB3F9908729667D414BFF31 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Hi all,

The draft below on happy eyeballs was submitted last night. It is on the agenda for Chicago, but we are happy to hear any comments you may have also before then.

Cheers,
Anna

-------- Forwarded Message --------
Subject: New Version Notification for draft-grinnemo-taps-he-02.txt
Date: Mon, 13 Mar 2017 11:18:59 -0700
From: internet-drafts@ietf.org
To: Zdravko Bozakov <Zdravko.Bozakov@dell.com>, Zdravko Bozakov <zdravko.bozakov@dell.com>, Anna Brunstrom <anna.brunstrom@kau.se>, Per Hurtig <per.hurtig@kau.se>, Karl-Johan Grinnemo <karl-johan.grinnemo@kau.se>, Naeem Khademi <naeemk@ifi.uio.no> 


A new version of I-D, draft-grinnemo-taps-he-02.txt
has been successfully submitted by Karl-Johan Grinnemo and posted to the
IETF repository.

Name:		draft-grinnemo-taps-he
Revision:	02
Title:		Happy Eyeballs for Transport Selection
Document date:	2017-03-13
Group:		Individual Submission
Pages:		10
URL:            https://www.ietf.org/internet-drafts/draft-grinnemo-taps-he-02.txt
Status:         https://datatracker.ietf.org/doc/draft-grinnemo-taps-he/
Htmlized:       https://tools.ietf.org/html/draft-grinnemo-taps-he-02
Diff:           https://www.ietf.org/rfcdiff?url2=draft-grinnemo-taps-he-02

Abstract:
   Ideally, network applications should be able to select an appropriate
   transport solution from among available transport solutions.
   However, at present, there is no agreed-upon way to do this.  In
   fact, there is not even an agreed-upon way for a source end host to
   determine if there is support for a particular transport along a
   network path.  This draft addresses these issues, by proposing a
   Happy Eyeballs framework.  The proposed Happy Eyeballs framework
   enables the selection of a transport solution that according to
   application requirements, pre-set policies, and estimated network
   conditions is the most appropriate one.  Additionally, the proposed
   framework makes it possible for an application to find out whether a
   particular transport is supported along a network connection towards
   a specific destination or not.

                                                                                  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat
--------------0AB3F9908729667D414BFF31-- From nobody Fri Mar 17 09:41:36 2017 Return-Path: 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 BED741294CA for ; Fri, 17 Mar 2017 09:41:34 -0700 (PDT) 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 YkgQ1cnAC7l9 for ; Fri, 17 Mar 2017 09:41:32 -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 2EA13129462 for ; Fri, 17 Mar 2017 09:41:32 -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 ) id 1couwU-0000SB-DI for taps@ietf.org; Fri, 17 Mar 2017 17:41:30 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx02.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1couwT-0003DQ-NC for taps@ietf.org; Fri, 17 Mar 2017 17:41:30 +0100 From: Michael Welzl Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <735DD439-E086-4294-86F3-3B9DCE7F7924@ifi.uio.no> Date: Fri, 17 Mar 2017 17:41:29 +0100 To: taps WG Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx02.uio.no: 129.240.68.135 is neither permitted nor denied by domain of ifi.uio.no) client-ip=129.240.68.135; envelope-from=michawe@ifi.uio.no; helo=boomerang.ifi.uio.no; X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 3 sum rcpts/h 5 sum msgs/h 5 total rcpts 52871 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.008, RP_MATCHES_RCVD=-0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 5DE2F4DD8D8E8A01A4C53F635314C043AC333393 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 12678 max/h 21 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: [Taps] NEAT's abstract API: an old snapshot showing our design process X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 16:41:35 -0000 Dear all, I'm writing this on behalf of the NEAT project: We have decided to release a relatively old snapshot of a document that = is continuously evolving (our "deliverable D1.2"), just to give folks an idea about the design process that we use to develop our own = API. It's about how we get from IETF drafts (and, in our case, also requirements derived from use cases) to running code. We thought that this would be of interest to the TAPS community - here's = the link: https://www.neat-project.org/2017/03/abstract-api-description-released/ Again, I'd like to stress that this does *not* capture the current state = of NEAT - it captures a significantly older state of it, in the form of = an abstract API, illustrating our design process. (our concrete API is also quite different in style - many of the = "primitives" in this abstract API are just elements of a data structure = in our actual call-back-based implementation). With this, I wish y'all a nice weekend, Michael From nobody Tue Mar 21 00:23:21 2017 Return-Path: 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 3842412957C for ; Tue, 21 Mar 2017 00:23:11 -0700 (PDT) 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 Orqx-zjXIKOG for ; Tue, 21 Mar 2017 00:23:05 -0700 (PDT) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (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 B577E12956A for ; Tue, 21 Mar 2017 00:23:05 -0700 (PDT) Received: from mail-mx03.uio.no ([129.240.10.15]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cqE8F-0000Zi-J0 for taps@ietf.org; Tue, 21 Mar 2017 08:23:03 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx03.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cqE8E-0007JX-Qs for taps@ietf.org; Tue, 21 Mar 2017 08:23:03 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: Date: Tue, 21 Mar 2017 08:23:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <91EEB4A3-06C8-4138-A05F-19E3BD9E3CF6@ifi.uio.no> References: <148942050575.17043.6419886474129053646.idtracker@ietfa.amsl.com> To: "taps@ietf.org" X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx03.uio.no: 129.240.68.135 is neither permitted nor denied by domain of ifi.uio.no) client-ip=129.240.68.135; envelope-from=michawe@ifi.uio.no; helo=boomerang.ifi.uio.no; X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 2 sum rcpts/h 9 sum msgs/h 3 total rcpts 52957 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.005, RP_MATCHES_RCVD=-0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 1F852041DE621BCF8AFDA5FD8EF7DEE8D2017081 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 12717 max/h 21 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [Taps] New Version Notification for draft-gjessing-taps-minset-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 07:23:11 -0000 Hi everyone, With one week having passed since this posting, and one week to go until = the meeting, I thought I'd send a reminder - folks, please consider = taking a look at this. For a fast way of reading this: - keep in mind that we removed all transport features that either don't = require application-specific knowledge (knowledge that only applications = have) or don't have a fall-back to TCP - start reading from section 4 ! This gives you about 13 pages to read = instead of the total 35'ish, and it contains all the ineresting stuff. = The pretty long section 3 can be used to go back and check, for things = that make you go "huh??". Thanks! Michael > On 13 Mar 2017, at 17:06, Michael Welzl wrote: >=20 > Dear TAPS WG, >=20 > This update addresses the feedback that we got at the last meeting: = people said that this minset isn't much of a minset. ... that's because = we had only worked on the first step: categorizing transport features = such that the list can then be reduced. >=20 > Now, in this update: > - we've brought the list in line with the latest version of the -usage = draft (the list is a lot longer now, and includes what we think are = *all* transport features of TCP, MPTCP, SCTP, UDP(-Lite) ... except for = TCP Authentication. We'll fix this one in the next version. > - we then shortened the list brutally :) by only allowing = "functional" and "optimizing" transport features, and also removing = transport features for which it doesn't seem possible to fall back to = TCP > - we then wrote text discussing the strange list that we got ... some = weird things there need consideration when designing a TAPS system > - and then we made a first stab at constructing a "minimum set", = derived from the above. >=20 > I hope folks will find this interesting despite its length - it = captures several things that I've had in mind for a while, and partially = talked about to people, but never really wrote up anywhere. A lot of = love has gone into this document ;-) >=20 > Cheers, > Michael >=20 >=20 >=20 >> Begin forwarded message: >>=20 >> From: >> Subject: New Version Notification for = draft-gjessing-taps-minset-04.txt >> Date: 13 Mar 2017 16:55:05 CET >> To: Michael Welzl , Stein Gjessing = >> Resent-From: >>=20 >>=20 >> A new version of I-D, draft-gjessing-taps-minset-04.txt >> has been successfully submitted by Michael Welzl and posted to the >> IETF repository. >>=20 >> Name: draft-gjessing-taps-minset >> Revision: 04 >> Title: A Minimal Set of Transport Services for TAPS = Systems >> Document date: 2017-03-13 >> Group: Individual Submission >> Pages: 38 >> URL: = https://www.ietf.org/internet-drafts/draft-gjessing-taps-minset-04.txt >> Status: = https://datatracker.ietf.org/doc/draft-gjessing-taps-minset/ >> Htmlized: = https://tools.ietf.org/html/draft-gjessing-taps-minset-04 >> Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-gjessing-taps-minset-04 >>=20 >> Abstract: >> This draft recommends a minimal set of IETF Transport Services >> offered by end systems supporting TAPS, and gives guidance on >> choosing among the available mechanisms and protocols. It is based >> on the set of transport features given in the TAPS document >> draft-ietf-taps-transports-usage-03. >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> The IETF Secretariat >>=20 >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Tue Mar 21 01:06:17 2017 Return-Path: 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 DAEC8129666 for ; Tue, 21 Mar 2017 01:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 4wbgq3ahr6ds for ; Tue, 21 Mar 2017 01:06:14 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2A37129663 for ; Tue, 21 Mar 2017 01:06:13 -0700 (PDT) Received: from mail-ot0-f178.google.com (mail-ot0-f178.google.com [74.125.82.178]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 26A4129C6BD for ; Tue, 21 Mar 2017 17:06:12 +0900 (JST) Received: by mail-ot0-f178.google.com with SMTP id o24so146878088otb.1 for ; Tue, 21 Mar 2017 01:06:12 -0700 (PDT) X-Gm-Message-State: AFeK/H37mCjySNHZnvpsq82AI5ovnNtHovB0EfEeAsDOmqsqobaUYJ7sOhTdbOKtGLkUA3r0AKpSan8IsqNgUg== X-Received: by 10.157.31.57 with SMTP id x54mr16201712otd.186.1490083570059; Tue, 21 Mar 2017 01:06:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.82.27 with HTTP; Tue, 21 Mar 2017 01:06:09 -0700 (PDT) In-Reply-To: <1D4A0D56-6499-488C-9EE5-5CA33980B7E1@ifi.uio.no> References: <148896186226.26267.9891445617205312227@ietfa.amsl.com> <1D4A0D56-6499-488C-9EE5-5CA33980B7E1@ifi.uio.no> From: Yoshifumi Nishida Date: Tue, 21 Mar 2017 01:06:09 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Michael Welzl Cc: "taps@ietf.org" Content-Type: multipart/alternative; boundary=001a113d054ae11a35054b391dda Archived-At: Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-usage-03.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 08:06:16 -0000 --001a113d054ae11a35054b391dda Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Mar 9, 2017 at 7:43 AM, Michael Welzl wrote: > > > On Mar 8, 2017, at 9:36 AM, Michael Welzl wrote: > > > > Dear all, > > > > This is a quite major update: from our (author's) point of view, it now > (at last!) captures all the RFC-defined API primitives / transport featur= es > of TCP, MPTCP, SCTP, UDP(-Lite) and LEDBAT. > > Sigh, with one exception - I had a plan to include it but when I checked > again I overlooked section 7.1: TCP-AO (RFC 5925) requires some changes t= o > the TCP user interface, not covered in this document. That one will go in= to > the next update, together with any other suggestions we=E2=80=99ll receiv= e=E2=80=A6 > > This is just out of my curiosity... Why there is no mention on DCCP in the draft while we there are some descriptions of DCCP in RFC8095? I am just curious about the reason for it. Sorry if this has already been discussed. -- Yoshi --001a113d054ae11a35054b391dda Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Mar 9, 2017 at 7:43 AM, Michael Welzl <michawe@ifi.uio.no> wrote:

> On Mar 8, 2017, at 9:36 AM, Michael Welzl <michawe@ifi.uio.no> wrote:
>
> Dear all,
>
> This is a quite major update: from our (author's) point of view, i= t now (at last!) captures all the RFC-defined API primitives / transport fe= atures of TCP, MPTCP, SCTP, UDP(-Lite) and LEDBAT.

Sigh, with one exception - I had a plan to include it but when I che= cked again I overlooked section 7.1: TCP-AO (RFC 5925) requires some change= s to the TCP user interface, not covered in this document. That one will go= into the next update, together with any other suggestions we=E2=80=99ll re= ceive=E2=80=A6

T= his is just out of my curiosity...=C2=A0
Why there is no mention = on DCCP in the draft while we there are some descriptions of DCCP in RFC809= 5? I am just curious about the reason for it. Sorry if this has already bee= n discussed.
--
Yoshi=C2=A0
=C2=A0
--001a113d054ae11a35054b391dda-- From nobody Tue Mar 21 01:35:12 2017 Return-Path: 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 C1E57129693 for ; Tue, 21 Mar 2017 01:35:10 -0700 (PDT) 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 KABlHGXBgEMc for ; Tue, 21 Mar 2017 01:35:08 -0700 (PDT) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (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 C782D12932A for ; Tue, 21 Mar 2017 01:35:07 -0700 (PDT) Received: from mail-mx06.uio.no ([129.240.10.40]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cqFFy-0005Yu-6U; Tue, 21 Mar 2017 09:35:06 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx06.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cqFFx-0004D6-BV; Tue, 21 Mar 2017 09:35:06 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: Date: Tue, 21 Mar 2017 09:35:02 +0100 Cc: "taps@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <25624252-6E3B-4EE1-93F5-53523FAE0C4E@ifi.uio.no> References: <148896186226.26267.9891445617205312227@ietfa.amsl.com> <1D4A0D56-6499-488C-9EE5-5CA33980B7E1@ifi.uio.no> To: Yoshifumi Nishida X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx06.uio.no: 129.240.68.135 is neither permitted nor denied by domain of ifi.uio.no) client-ip=129.240.68.135; envelope-from=michawe@ifi.uio.no; helo=boomerang.ifi.uio.no; X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 3 sum rcpts/h 10 sum msgs/h 5 total rcpts 52965 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.011, RP_MATCHES_RCVD=-0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: B05CA752D55F7BBE19542DE1F35AC940E8D14979 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 12722 max/h 21 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-usage-03.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 08:35:11 -0000 > On 21 Mar 2017, at 09:06, Yoshifumi Nishida = wrote: >=20 > On Thu, Mar 9, 2017 at 7:43 AM, Michael Welzl = wrote: >=20 > > On Mar 8, 2017, at 9:36 AM, Michael Welzl = wrote: > > > > Dear all, > > > > This is a quite major update: from our (author's) point of view, it = now (at last!) captures all the RFC-defined API primitives / transport = features of TCP, MPTCP, SCTP, UDP(-Lite) and LEDBAT. >=20 > Sigh, with one exception - I had a plan to include it but when I = checked again I overlooked section 7.1: TCP-AO (RFC 5925) requires some = changes to the TCP user interface, not covered in this document. That = one will go into the next update, together with any other suggestions = we=E2=80=99ll receive=E2=80=A6 >=20 > This is just out of my curiosity...=20 > Why there is no mention on DCCP in the draft while we there are some = descriptions of DCCP in RFC8095? I am just curious about the reason for = it. Sorry if this has already been discussed. RFC 8095 contains many more things that this one doesn't contain... We did have someone signed up to write the DCCP stuff but it never = happened, so at some point we had to give up on it. At some past = meeting, we checked with the TAPS group to agree on the list of = protocols that this draft now contains. Cheers, Michael From nobody Tue Mar 21 15:42:19 2017 Return-Path: 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 D4D441276AF for ; Tue, 21 Mar 2017 15:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 ZQK_xYx5VlBY for ; Tue, 21 Mar 2017 15:42:15 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 C59A21296C3 for ; Tue, 21 Mar 2017 15:42:15 -0700 (PDT) Received: from [128.9.184.179] ([128.9.184.179]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v2LMfRhG018704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 21 Mar 2017 15:41:28 -0700 (PDT) To: Anna Brunstrom , "taps@ietf.org" References: <148942913904.9187.9087920412455130356.idtracker@ietfa.amsl.com> <9fcb9fc9-4cd9-38e7-c51c-d376f01b933d@kau.se> From: Joe Touch Message-ID: <71f52e2e-c156-bfad-488d-f88e83cde141@isi.edu> Date: Tue, 21 Mar 2017 15:41:27 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <9fcb9fc9-4cd9-38e7-c51c-d376f01b933d@kau.se> Content-Type: multipart/alternative; boundary="------------9D9800FE15B91335F9506411" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Taps] Fwd: New Version Notification for draft-grinnemo-taps-he-02.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 22:42:18 -0000 This is a multi-part message in MIME format. --------------9D9800FE15B91335F9506411 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Hi, all, Some observations: - HE-trans MUST NOT be used to try different combinations of options within a given transport - I'm wondering about the potential for problems when ports are reused between different attempts, e.g., IPv6-TCP then IPv4-TCP - the document works only for connection-orient transports that treat failed connections as "no information" if a connection fails for other reasons, the origin might receive an ICMP message that prohibits further attempts, either to that transport, port, or address if a connection attempt is rejected but used as information, you could end up with confusing results (e.g., as a covert channel) in that case, you're not doing HE; IMO, HE requires that there be no impact to failed attempts Joe On 3/14/2017 2:37 AM, Anna Brunstrom wrote: > > Hi all, > > The draft below on happy eyeballs was submitted last night. It is on > the agenda for Chicago, but we are happy to hear any comments you may > have also before then. > > Cheers, > Anna > > -------- Forwarded Message -------- > Subject: New Version Notification for draft-grinnemo-taps-he-02.txt > Date: Mon, 13 Mar 2017 11:18:59 -0700 > From: internet-drafts@ietf.org > To: Zdravko Bozakov , Zdravko Bozakov > , Anna Brunstrom , > Per Hurtig , Karl-Johan Grinnemo > , Naeem Khademi > > > > A new version of I-D, draft-grinnemo-taps-he-02.txt > has been successfully submitted by Karl-Johan Grinnemo and posted to the > IETF repository. > > Name: draft-grinnemo-taps-he > Revision: 02 > Title: Happy Eyeballs for Transport Selection > Document date: 2017-03-13 > Group: Individual Submission > Pages: 10 > URL: https://www.ietf.org/internet-drafts/draft-grinnemo-taps-he-02.txt > Status: https://datatracker.ietf.org/doc/draft-grinnemo-taps-he/ > Htmlized: https://tools.ietf.org/html/draft-grinnemo-taps-he-02 > Diff: https://www.ietf.org/rfcdiff?url2=draft-grinnemo-taps-he-02 > > Abstract: > Ideally, network applications should be able to select an appropriate > transport solution from among available transport solutions. > However, at present, there is no agreed-upon way to do this. In > fact, there is not even an agreed-upon way for a source end host to > determine if there is support for a particular transport along a > network path. This draft addresses these issues, by proposing a > Happy Eyeballs framework. The proposed Happy Eyeballs framework > enables the selection of a transport solution that according to > application requirements, pre-set policies, and estimated network > conditions is the most appropriate one. Additionally, the proposed > framework makes it possible for an application to find out whether a > particular transport is supported along a network connection towards > a specific destination or not. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --------------9D9800FE15B91335F9506411 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hi, all,

Some observations:

- HE-trans MUST NOT be used to try different combinations of options within a given transport

- I'm wondering about the potential for problems when ports are reused between different attempts, e.g., IPv6-TCP then IPv4-TCP

- the document works only for connection-orient transports that treat failed connections as "no information"

    if a connection fails for other reasons, the origin might receive an ICMP message that prohibits further attempts, either to that transport, port, or address

    if a connection attempt is rejected but used as information, you could end up with confusing results (e.g., as a covert channel)

    in that case, you're not doing HE; IMO, HE requires that there be no impact to failed attempts

Joe


On 3/14/2017 2:37 AM, Anna Brunstrom wrote:

Hi all,

The draft below on happy eyeballs was submitted last night. It is on the agenda for Chicago, but we are happy to hear any comments you may have also before then.

Cheers,
Anna

-------- Forwarded Message --------
Subject: New Version Notification for draft-grinnemo-taps-he-02.txt
Date: Mon, 13 Mar 2017 11:18:59 -0700
From: internet-drafts@ietf.org
To: Zdravko Bozakov <Zdravko.Bozakov@dell.com>, Zdravko Bozakov <zdravko.bozakov@dell.com>, Anna Brunstrom <anna.brunstrom@kau.se>, Per Hurtig <per.hurtig@kau.se>, Karl-Johan Grinnemo <karl-johan.grinnemo@kau.se>, Naeem Khademi <naeemk@ifi.uio.no> 


A new version of I-D, draft-grinnemo-taps-he-02.txt
has been successfully submitted by Karl-Johan Grinnemo and posted to the
IETF repository.

Name:		draft-grinnemo-taps-he
Revision:	02
Title:		Happy Eyeballs for Transport Selection
Document date:	2017-03-13
Group:		Individual Submission
Pages:		10
URL:            https://www.ietf.org/internet-drafts/draft-grinnemo-taps-he-02.txt
Status:         https://datatracker.ietf.org/doc/draft-grinnemo-taps-he/
Htmlized:       https://tools.ietf.org/html/draft-grinnemo-taps-he-02
Diff:           https://www.ietf.org/rfcdiff?url2=draft-grinnemo-taps-he-02

Abstract:
   Ideally, network applications should be able to select an appropriate
   transport solution from among available transport solutions.
   However, at present, there is no agreed-upon way to do this.  In
   fact, there is not even an agreed-upon way for a source end host to
   determine if there is support for a particular transport along a
   network path.  This draft addresses these issues, by proposing a
   Happy Eyeballs framework.  The proposed Happy Eyeballs framework
   enables the selection of a transport solution that according to
   application requirements, pre-set policies, and estimated network
   conditions is the most appropriate one.  Additionally, the proposed
   framework makes it possible for an application to find out whether a
   particular transport is supported along a network connection towards
   a specific destination or not.

                                                                                  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

--------------9D9800FE15B91335F9506411-- From nobody Wed Mar 22 12:01:13 2017 Return-Path: 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 1EE4C129C37 for ; Wed, 22 Mar 2017 12:01:10 -0700 (PDT) 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=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 x6F6tyI9JRCn for ; Wed, 22 Mar 2017 12:01:06 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (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 861571294FD for ; Wed, 22 Mar 2017 12:00:56 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id v127so163845326qkb.2 for ; Wed, 22 Mar 2017 12:00:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=epu+e6odL9uy/fnyDAM60NQUDNNni0KS+e+BW6XD7Wk=; b=BSxVdqtrzD32u8qQlHkKx76/L8l+rjR5C+udLUdvWrm44DKGvai016eFQfFZrH2aN7 6PGRSrnS/+kzGVwIFyC1nTWDRuo2atO9uJYspwiB/Q+4JuOWwEOabA+23VnFFUjW/Uz+ QBA1TN5FY+F1HRKHN+eyGB9kW03Jtk8tZ53TVUhyhDEKbbduPCyBXJ8UJo2KTT5j8cHa t0RglfY5fFT18OVwkLHCgLqBLFcdIrkVYc+6Uq0mL4Oaif2Lduvk3ZxlDV8IrmlT4RSq qqA/n1qCJkvynoEMvaRV89d9Qodzayh/gj7oDtkiQoSTSIWOXQSm6Sh6Wen0rX25PfZC gu2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=epu+e6odL9uy/fnyDAM60NQUDNNni0KS+e+BW6XD7Wk=; b=n5NuGcTDtRSwHToT+4RFVtZ3ifPP8PupcTostb4aIOPJAFN0sOG027owMzLAyAhN4O RMeIpSTJNLkicWwvawaFDvwwdvmvq0dUd1XkOrno8JWDdXhCHIKqtPDrxrwjnsFDlcVT QzNKBfWWaeEAJxoLw1QcMJqET1c9pbRbgXp/qgPQXhFujwzw9Axb61rlxlXdCc8chTk9 XLE3ktxaXsa/p3vlWihVvpZJABuK3RWjKbmeriqPGSPFvxQaXjDV88fmHLKP8JDOHkRu +hMDyPXNpULMuRMpS9sP/juujd2h2Z59H5tA6tojZbeQonR2aJmMbYqM8NAiF5wRS3p7 Ex3w== X-Gm-Message-State: AFeK/H00b56+VqwKXa5MqwMxeU459FAJc8Om7WxVBGtTmXUiFVtiiUjGOCYHI6ATU7SJgw== X-Received: by 10.55.22.131 with SMTP id 3mr7772798qkw.33.1490209254812; Wed, 22 Mar 2017 12:00:54 -0700 (PDT) Received: from [172.19.32.143] ([2001:4878:8000:60:396d:674b:26d8:1dac]) by smtp.gmail.com with ESMTPSA id r55sm1577758qtr.16.2017.03.22.12.00.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Mar 2017 12:00:53 -0700 (PDT) From: "Aaron Falk" To: "taps@ietf.org" Cc: "Michael Welzl" Date: Wed, 22 Mar 2017 15:00:53 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_AA455CCF-7F8C-41C1-A560-D09EF7BAC298_=" Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5356) Archived-At: Subject: [Taps] IMPORTANT IETF pre-work X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 19:01:10 -0000 --=_MailMate_AA455CCF-7F8C-41C1-A560-D09EF7BAC298_= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit While [the mindset doc](https://www.ietf.org/internet-drafts/draft-gjessing-taps-minset-04.txt) isn’t final (there are a few TBDs), it is mostly complete. As it is one of our deliverables it needs a thorough review. Please come to the wg meeting prepared to discuss whether you think the document is ready for wg last call and, if not, what your concerns are. Thanks, —aaron On 21 Mar 2017, at 3:23, Michael Welzl wrote: > Hi everyone, > > With one week having passed since this posting, and one week to go > until the meeting, I thought I'd send a reminder - folks, please > consider taking a look at this. > For a fast way of reading this: > > - keep in mind that we removed all transport features that either > don't require application-specific knowledge (knowledge that only > applications have) or don't have a fall-back to TCP > - start reading from section 4 ! This gives you about 13 pages to > read instead of the total 35'ish, and it contains all the ineresting > stuff. The pretty long section 3 can be used to go back and check, for > things that make you go "huh??". > > Thanks! > Michael > > >> On 13 Mar 2017, at 17:06, Michael Welzl wrote: >> >> Dear TAPS WG, >> >> This update addresses the feedback that we got at the last meeting: >> people said that this minset isn't much of a minset. ... that's >> because we had only worked on the first step: categorizing transport >> features such that the list can then be reduced. >> >> Now, in this update: >> - we've brought the list in line with the latest version of the >> -usage draft (the list is a lot longer now, and includes what we >> think are *all* transport features of TCP, MPTCP, SCTP, UDP(-Lite) >> ... except for TCP Authentication. We'll fix this one in the next >> version. >> - we then shortened the list brutally :) by only allowing >> "functional" and "optimizing" transport features, and also removing >> transport features for which it doesn't seem possible to fall back to >> TCP >> - we then wrote text discussing the strange list that we got ... some >> weird things there need consideration when designing a TAPS system >> - and then we made a first stab at constructing a "minimum set", >> derived from the above. >> >> I hope folks will find this interesting despite its length - it >> captures several things that I've had in mind for a while, and >> partially talked about to people, but never really wrote up anywhere. >> A lot of love has gone into this document ;-) >> >> Cheers, >> Michael >> >> >> >>> Begin forwarded message: >>> >>> From: >>> Subject: New Version Notification for >>> draft-gjessing-taps-minset-04.txt >>> Date: 13 Mar 2017 16:55:05 CET >>> To: Michael Welzl , Stein Gjessing >>> >>> Resent-From: >>> >>> >>> A new version of I-D, draft-gjessing-taps-minset-04.txt >>> has been successfully submitted by Michael Welzl and posted to the >>> IETF repository. >>> >>> Name: draft-gjessing-taps-minset >>> Revision: 04 >>> Title: A Minimal Set of Transport Services for TAPS Systems >>> Document date: 2017-03-13 >>> Group: Individual Submission >>> Pages: 38 >>> URL: >>> https://www.ietf.org/internet-drafts/draft-gjessing-taps-minset-04.txt >>> Status: >>> https://datatracker.ietf.org/doc/draft-gjessing-taps-minset/ >>> Htmlized: >>> https://tools.ietf.org/html/draft-gjessing-taps-minset-04 >>> Diff: >>> https://www.ietf.org/rfcdiff?url2=draft-gjessing-taps-minset-04 >>> >>> Abstract: >>> This draft recommends a minimal set of IETF Transport Services >>> offered by end systems supporting TAPS, and gives guidance on >>> choosing among the available mechanisms and protocols. It is based >>> on the set of transport features given in the TAPS document >>> draft-ietf-taps-transports-usage-03. >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> The IETF Secretariat >>> >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps --=_MailMate_AA455CCF-7F8C-41C1-A560-D09EF7BAC298_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

H= i everyone,

With one week having passed since this posting, and one week to go until = the meeting, I thought I'd send a reminder - folks, please consider takin= g a look at this.
For a fast way of reading this:

- keep in mind that we removed all transport features that either don't r= equire application-specific knowledge (knowledge that only applications h= ave) or don't have a fall-back to TCP
- start reading from section 4 ! This gives you about 13 pages to read = instead of the total 35'ish, and it contains all the ineresting stuff. Th= e pretty long section 3 can be used to go back and check, for things that= make you go "huh??".

Thanks!
Michael

On 13 Mar 2= 017, at 17:06, Michael Welzl <michawe@ifi.uio.no> wrote:

Dear TAPS WG,

This update addresses the feedback that we got at the last meeting: peopl= e said that this minset isn't much of a minset. ... that's because we had= only worked on the first step: categorizing transport features such that= the list can then be reduced.

Now, in this update:
- we've brought the list in line with the latest version of the -usage dr= aft (the list is a lot longer now, and includes what we think are *all* t= ransport features of TCP, MPTCP, SCTP, UDP(-Lite) ... except for TCP Auth= entication. We'll fix this one in the next version.
- we then shortened the list brutally :) by only allowing "functional"= and "optimizing" transport features, and also removing transport feature= s for which it doesn't seem possible to fall back to TCP
- we then wrote text discussing the strange list that we got ... some wei= rd things there need consideration when designing a TAPS system
- and then we made a first stab at constructing a "minimum set", derived = from the above.

I hope folks will find this interesting despite its length - it captures = several things that I've had in mind for a while, and partially talked ab= out to people, but never really wrote up anywhere. A lot of love has gone= into this document ;-)

Cheers,
Michael


Begin forwa= rded message:

From: <internet-drafts@ietf.org>
Subject: New Version Notification for draft-gjessing-taps-minset-04.txt Date: 13 Mar 2017 16:55:05 CET
To: Michael Welzl <michawe@ifi.uio.no>, Stein Gjessing <steing@i= fi.uio.no>
Resent-From: <michawe@ifi.uio.no>


A new version of I-D, draft-gjessing-taps-minset-04.txt
has been successfully submitted by Michael Welzl and posted to the
IETF repository.

Name: draft-gjessing-taps-minset
Revision: 04
Title: A Minimal Set of Transport Services for TAPS Systems
Document date: 2017-03-13
Group: Individual Submission
Pages: 38
URL: https://www.ietf.org/inter= net-drafts/draft-gjessing-taps-minset-04.txt
Status: https://datatracker.ietf.org/doc/dra= ft-gjessing-taps-minset/
Htmlized: https://tools.ietf.org/html/draft-gjess= ing-taps-minset-04
Diff: https://www.ietf.org/rfcdiff?ur= l2=3Ddraft-gjessing-taps-minset-04

Abstract:
This draft recommends a minimal set of IETF Transport Services
offered by end systems supporting TAPS, and gives guidance on
choosing among the available mechanisms and protocols. It is based
on the set of transport features given in the TAPS document
draft-ietf-taps-transports-usage-03.




Please note that it may take a couple of minutes from the time of submiss= ion
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

____________________________________________= ___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

--=_MailMate_AA455CCF-7F8C-41C1-A560-D09EF7BAC298_=-- From nobody Wed Mar 22 14:01:57 2017 Return-Path: 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 0EF19128C83 for ; Wed, 22 Mar 2017 14:01:55 -0700 (PDT) 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=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 T2uhtZeGlfnL for ; Wed, 22 Mar 2017 14:01:52 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d: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 1725B128BBB for ; Wed, 22 Mar 2017 14:01:52 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id p64so165797043qke.1 for ; Wed, 22 Mar 2017 14:01:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:embedded-html; bh=PKGRFllR80BCh6uH62w9VpawtlvX8kDoAlH4/RHdJC0=; b=daeDrueTclSm0hFtB8ItT8MXayuFTaI6fYOOIkG1f9+BtQiK5S11bCFP0sW4ke1fwQ ZffxinX0yOcpwkeb7zuAjtDHHEg47Se8L4mN4S7K+k6j89OBO0uj2Okin66dw3V45Zwd gN6p9Ky26qbA+EvBtXukezDK0Kqj9bgmAw5H0RnqPWWssFtMIIa8vrmzBeJsos+8U+C3 BghdBstwaRledTd70CeadNcK++hfEkW7yw30WieXW3vllaUc6eGp6mm6FA12Q0CmN0vK dWV+okYGoAyAf2+KjIFP0An6mAb+ygmgRI4lA0zix6PjRdwzPgWx0B6OAyqC6x0nbfRE M5BQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding:embedded-html; bh=PKGRFllR80BCh6uH62w9VpawtlvX8kDoAlH4/RHdJC0=; b=QEkM0M5J+agijA8W0630T1NvsIYVoJDgrBj3hb65IiTP1f+eRQHp28PDR61kyXS8L2 bw/ZMNHEObhUULIdyBGR4wfWtkNl38GyBMIt2PnaxLkWUaflGwV+nhugqw3UkLKj46Zk IDaJKZIRXfJAZs0VT0MPTWyvDqNCaC0IMlgftKmlmyMdhn8CEshSTAEfM3Ix7mjO+8ig jl+7fl9W19OyERIM3KUdx4ypsSHGd4csO64Fc0wgFzUCPUZNfaT42+DxMHvq2aD4w+0W QPiwFtvo5fceSVQkOa5y/lkfhYtu7WOu6EvpFAeRLX+qwj8EowpdNDedD32yLBcVMk46 KFYg== X-Gm-Message-State: AFeK/H1AbkTvPmolR1WVQRuiM0eeNYG7H+XdkXnK0JWUowfxZKjgobLSLL2ZhVKl9L7L7A== X-Received: by 10.55.119.65 with SMTP id s62mr36417034qkc.130.1490216510048; Wed, 22 Mar 2017 14:01:50 -0700 (PDT) Received: from [172.19.33.255] ([2001:4878:8000:60:2c3e:6ce1:6f8:1b81]) by smtp.gmail.com with ESMTPSA id c144sm1799808qkg.8.2017.03.22.14.01.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Mar 2017 14:01:49 -0700 (PDT) From: "Aaron Falk" To: "taps@ietf.org" Cc: "Michael Welzl" Date: Wed, 22 Mar 2017 17:01:49 -0400 Message-ID: <0FC3F693-07AA-4A98-AE01-AA0238CA27B5@gmail.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_79467A75-3365-41B6-B439-4FAE7DD0625A_=" Content-Transfer-Encoding: 8bit Embedded-HTML: [{"HTML":[715, 5464], "plain":[262, 4228], "uuid":"9350C9C8-AA15-4FED-81C8-A2853BA9FE67"}] X-Mailer: MailMate (1.9.6r5356) Archived-At: Subject: Re: [Taps] IMPORTANT IETF pre-work X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 21:01:55 -0000 --=_MailMate_79467A75-3365-41B6-B439-4FAE7DD0625A_= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Clarification: the request is to consider the minset (not mindset, thanks spellcheck) doc for **adoption**, not last call. Please try to look at it in advance. —aaron (who’s having trouble with email today) On 22 Mar 2017, at 15:00, Aaron Falk wrote: > While [the mindset > doc](https://www.ietf.org/internet-drafts/draft-gjessing-taps-minset-04.txt) > isn’t final (there are a few TBDs), it is mostly complete. As it is > one of our deliverables it needs a thorough review. Please come to > the wg meeting prepared to discuss whether you think the document is > ready for wg last call and, if not, what your concerns are. > > Thanks, > > —aaron > > On 21 Mar 2017, at 3:23, Michael Welzl wrote: > >> Hi everyone, >> >> With one week having passed since this posting, and one week to go >> until the meeting, I thought I'd send a reminder - folks, please >> consider taking a look at this. >> For a fast way of reading this: >> >> - keep in mind that we removed all transport features that either >> don't require application-specific knowledge (knowledge that only >> applications have) or don't have a fall-back to TCP >> - start reading from section 4 ! This gives you about 13 pages to >> read instead of the total 35'ish, and it contains all the ineresting >> stuff. The pretty long section 3 can be used to go back and check, >> for things that make you go "huh??". >> >> Thanks! >> Michael >> >> >>> On 13 Mar 2017, at 17:06, Michael Welzl wrote: >>> >>> Dear TAPS WG, >>> >>> This update addresses the feedback that we got at the last meeting: >>> people said that this minset isn't much of a minset. ... that's >>> because we had only worked on the first step: categorizing transport >>> features such that the list can then be reduced. >>> >>> Now, in this update: >>> - we've brought the list in line with the latest version of the >>> -usage draft (the list is a lot longer now, and includes what we >>> think are *all* transport features of TCP, MPTCP, SCTP, UDP(-Lite) >>> ... except for TCP Authentication. We'll fix this one in the next >>> version. >>> - we then shortened the list brutally :) by only allowing >>> "functional" and "optimizing" transport features, and also removing >>> transport features for which it doesn't seem possible to fall back >>> to TCP >>> - we then wrote text discussing the strange list that we got ... >>> some weird things there need consideration when designing a TAPS >>> system >>> - and then we made a first stab at constructing a "minimum set", >>> derived from the above. >>> >>> I hope folks will find this interesting despite its length - it >>> captures several things that I've had in mind for a while, and >>> partially talked about to people, but never really wrote up >>> anywhere. A lot of love has gone into this document ;-) >>> >>> Cheers, >>> Michael >>> >>> >>> >>>> Begin forwarded message: >>>> >>>> From: >>>> Subject: New Version Notification for >>>> draft-gjessing-taps-minset-04.txt >>>> Date: 13 Mar 2017 16:55:05 CET >>>> To: Michael Welzl , Stein Gjessing >>>> >>>> Resent-From: >>>> >>>> >>>> A new version of I-D, draft-gjessing-taps-minset-04.txt >>>> has been successfully submitted by Michael Welzl and posted to the >>>> IETF repository. >>>> >>>> Name: draft-gjessing-taps-minset >>>> Revision: 04 >>>> Title: A Minimal Set of Transport Services for TAPS Systems >>>> Document date: 2017-03-13 >>>> Group: Individual Submission >>>> Pages: 38 >>>> URL: >>>> https://www.ietf.org/internet-drafts/draft-gjessing-taps-minset-04.txt >>>> Status: >>>> https://datatracker.ietf.org/doc/draft-gjessing-taps-minset/ >>>> Htmlized: >>>> https://tools.ietf.org/html/draft-gjessing-taps-minset-04 >>>> Diff: >>>> https://www.ietf.org/rfcdiff?url2=draft-gjessing-taps-minset-04 >>>> >>>> Abstract: >>>> This draft recommends a minimal set of IETF Transport Services >>>> offered by end systems supporting TAPS, and gives guidance on >>>> choosing among the available mechanisms and protocols. It is >>>> based >>>> on the set of transport features given in the TAPS document >>>> draft-ietf-taps-transports-usage-03. >>>> >>>> >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of >>>> submission >>>> until the htmlized version and diff are available at >>>> tools.ietf.org. >>>> >>>> The IETF Secretariat >>>> >>> >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps --=_MailMate_79467A75-3365-41B6-B439-4FAE7DD0625A_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Clarification: the request is to consider the minset (not= mindset, thanks spellcheck) doc for adoption, not last = call. Please try to look at it in advance.

=E2=80=94aaron (who=E2=80=99s having trouble with email t= oday)

On 22 Mar 2017, at 15:00, Aaron Falk wrote:

H= i everyone,

With one week having passed since this posting, and one week to go until = the meeting, I thought I'd send a reminder - folks, please consider takin= g a look at this.
For a fast way of reading this:

- keep in mind that we removed all transport features that either don't r= equire application-specific knowledge (knowledge that only applications h= ave) or don't have a fall-back to TCP
- start reading from section 4 ! This gives you about 13 pages to read = instead of the total 35'ish, and it contains all the ineresting stuff. Th= e pretty long section 3 can be used to go back and check, for things that= make you go "huh??".

Thanks!
Michael

On 13 Mar 2= 017, at 17:06, Michael Welzl <michawe@ifi.uio.no> wrote:

Dear TAPS WG,

This update addresses the feedback that we got at the last meeting: peopl= e said that this minset isn't much of a minset. ... that's because we had= only worked on the first step: categorizing transport features such that= the list can then be reduced.

Now, in this update:
- we've brought the list in line with the latest version of the -usage dr= aft (the list is a lot longer now, and includes what we think are *all* t= ransport features of TCP, MPTCP, SCTP, UDP(-Lite) ... except for TCP Auth= entication. We'll fix this one in the next version.
- we then shortened the list brutally :) by only allowing "functional"= and "optimizing" transport features, and also removing transport feature= s for which it doesn't seem possible to fall back to TCP
- we then wrote text discussing the strange list that we got ... some wei= rd things there need consideration when designing a TAPS system
- and then we made a first stab at constructing a "minimum set", derived = from the above.

I hope folks will find this interesting despite its length - it captures = several things that I've had in mind for a while, and partially talked ab= out to people, but never really wrote up anywhere. A lot of love has gone= into this document ;-)

Cheers,
Michael


Begin forwa= rded message:

From: <internet-drafts@ietf.org>
Subject: New Version Notification for draft-gjessing-taps-minset-04.txt Date: 13 Mar 2017 16:55:05 CET
To: Michael Welzl <michawe@ifi.uio.no>, Stein Gjessing <steing@i= fi.uio.no>
Resent-From: <michawe@ifi.uio.no>


A new version of I-D, draft-gjessing-taps-minset-04.txt
has been successfully submitted by Michael Welzl and posted to the
IETF repository.

Name: draft-gjessing-taps-minset
Revision: 04
Title: A Minimal Set of Transport Services for TAPS Systems
Document date: 2017-03-13
Group: Individual Submission
Pages: 38
URL: https://www.ietf.org/inter= net-drafts/draft-gjessing-taps-minset-04.txt
Status: https://datatracker.ietf.org/doc/dra= ft-gjessing-taps-minset/
Htmlized: https://tools.ietf.org/html/draft-gjess= ing-taps-minset-04
Diff: https://www.ietf.org/rfcdiff?ur= l2=3Ddraft-gjessing-taps-minset-04

Abstract:
This draft recommends a minimal set of IETF Transport Services
offered by end systems supporting TAPS, and gives guidance on
choosing among the available mechanisms and protocols. It is based
on the set of transport features given in the TAPS document
draft-ietf-taps-transports-usage-03.




Please note that it may take a couple of minutes from the time of submiss= ion
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

____________________________________________= ___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

--=_MailMate_79467A75-3365-41B6-B439-4FAE7DD0625A_=-- From nobody Fri Mar 24 16:05:32 2017 Return-Path: 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 D727A128D40 for ; Fri, 24 Mar 2017 16:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.358 X-Spam-Level: X-Spam-Status: No, score=-0.358 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, RP_MATCHES_RCVD=-0.001] autolearn=no 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 tAP5amyj2eXQ for ; Fri, 24 Mar 2017 16:05:29 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id A74CD12762F for ; Fri, 24 Mar 2017 16:05:28 -0700 (PDT) Received: from Gs-MacBook-Pro.local (unknown [216.80.70.251]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id E141B1B017C4; Sat, 25 Mar 2017 01:03:00 +0000 (GMT) Message-ID: <58D51F35.5020209@erg.abdn.ac.uk> Date: Fri, 24 Mar 2017 13:29:25 +0000 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: michawe@ifi.uio.no, steing@ifi.uio.no, taps@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Taps] Comments on draft-gjessing-taps-minset-02 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 23:05:31 -0000 This looks like good progress. A few very specific comments below: --- I see phrase: " Because QoS is out of scope of TAPS, this document assumes a "best effort" service model [RFC5290], [RFC7305]. " I'm not sure we need to state this. Although I agree that TAPS will not propose new QoS techniques, the service provided by TAPS is, I think, also not confinded to "best effort". --- I am not sure that IP options from UDP are entirely automatbale. Per-packet IP options could be related to application use of the network, and I think this would require some form of API interaction. --- I see LE service as something interesting, yet this does not exactly fit the rest of the draft. The cited reference is to a DiffServ PHB, and the LEDBAT referenced is a transport protocol mechanism, not a protocol. I'm not sure this inclusion is justified in the current tetx. --- Abort without delivering... Abortis currently specified for SCTP and TCP. If one assumes the bound semantics for UDP(Lite) this also seems also the correct primitive for UDP(Lite. Should this ID specify a connect primitive also for bound use of UDP(Lite)? --- What should be said about SCTP usage of IP OPTIONS? I would have expected if the endpoint network layer set these, they would also work for SCTP? --- Finally, I think I can agree the argument that UDP(Lite) message handling is different to SCTP. --- Gorry From nobody Sat Mar 25 14:38:35 2017 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C84201293F5 for ; Sat, 25 Mar 2017 14:38:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.48.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149047791381.11814.14966671082670520971.idtracker@ietfa.amsl.com> Date: Sat, 25 Mar 2017 14:38:33 -0700 From: IETF Secretariat Archived-At: Subject: [Taps] Milestones changed for taps WG X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Mar 2017 21:38:34 -0000 Changed milestone "Submit an Informational document to the IESG defining a set of services provided by IETF transport protocols and congestion control mechanisms", added draft-ietf-taps-transports-usage-udp to milestone. URL: https://datatracker.ietf.org/wg/taps/about/ From nobody Sun Mar 26 04:14:21 2017 Return-Path: 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 323381243FE for ; Sun, 26 Mar 2017 04:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 TVeuJdoDQLIb for ; Sun, 26 Mar 2017 04:14:17 -0700 (PDT) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (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 962E6124281 for ; Sun, 26 Mar 2017 04:14:17 -0700 (PDT) Received: from mail-mx03.uio.no ([129.240.10.15]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cs67j-00057c-Eh; Sun, 26 Mar 2017 13:14:15 +0200 Received: from swissotel07.s.subnet.rcn.com ([216.80.61.6] helo=[172.20.3.190]) by mail-mx03.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cs67i-0009yG-Gz; Sun, 26 Mar 2017 13:14:15 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Michael Welzl In-Reply-To: <58D51F35.5020209@erg.abdn.ac.uk> Date: Sun, 26 Mar 2017 06:14:14 -0500 Cc: Stein Gjessing , "taps@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <58D51F35.5020209@erg.abdn.ac.uk> To: " Fairhurst" X-Mailer: Apple Mail (2.3259) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx03.uio.no: 216.80.61.6 is neither permitted nor denied by domain of ifi.uio.no) client-ip=216.80.61.6; envelope-from=michawe@ifi.uio.no; helo=[172.20.3.190]; X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 9 sum msgs/h 3 total rcpts 53193 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 64474B17A34606150E31ADBBD62E9F6DDF03E709 X-UiO-SPAM-Test: remote_host: 216.80.61.6 spam_score: -49 maxlevel 80 minaction 1 bait 0 mail/h: 1 total 14 max/h 7 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [Taps] Comments on draft-gjessing-taps-minset-02 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Mar 2017 11:14:20 -0000 Hi, Thanks a lot for reading and commenting! > On Mar 24, 2017, at 8:29 AM, Gorry Fairhurst = wrote: >=20 > This looks like good progress. A few very specific comments below: >=20 > --- > I see phrase: > " Because QoS is out of scope of TAPS, this document assumes a "best > effort" service model [RFC5290], [RFC7305]. " >=20 > I'm not sure we need to state this. Although I agree that TAPS will = not propose new QoS techniques, the service provided by TAPS is, I = think, also not confinded to "best effort=E2=80=9D. Hmm... I was also thinking about the behavior of the actual TAPS system = in the end host, where you may ask for something but might not get it = (e.g. requested unordered message delivery might turn into ordered = bytestream delivery). So for now, best effort is indeed the underlying assumption - e.g. the = proposed =E2=80=9Ccapacity profile=E2=80=9D doesn=E2=80=99t come with = any guarantees, it *might* set the DSCP for you, and that *might* have a = certain effect. If we take that assumption away, the proposed system would be different = - it would have to fail and say =E2=80=9Cno, sorry=E2=80=9D more often, = which I don=E2=80=99t think is a good way ahead. What do you think? > --- > I am not sure that IP options from UDP are entirely automatbale. = Per-packet IP options could be related to application use of the = network, and I think this would require some form of API interaction. >=20 > =E2=80=94 We called everything that doesn=E2=80=99t require application-specific = knowledge (knowledge that only applications have) =E2=80=9Cautomatable=E2=80= =9D. So my first question is: what is it that only an application knows, = and that influences the choice of IP options? (generally though I=E2=80=99d be fine with introducing some transport = features that help the system do its automation - the conclusion talks = about this, using the choice of paths as an example). > I see LE service as something interesting, yet this does not exactly = fit the rest of the draft. The cited reference is to a DiffServ PHB, and = the LEDBAT referenced is a transport protocol mechanism, not a protocol. = I'm not sure this inclusion is justified in the current tetx. True that LEDBAT is a mechanism, not a protocol - but we specifically = wanted to include this in TAPS, which is why the charter mentions = =E2=80=9Ccongestion control mechanisms", in item 1: "Define a set of = Transport Services, identifying the services provided by existing IETF = protocols and congestion control mechanisms.=E2=80=9D I addressed this in the usage draft by making ** Enable and configure a = "Low Extra Delay Background Transfer=E2=80=9D ** a = CONNECTION.MAINTENANCE feature, i.e. something you use to configure a = connection. This seems to me to be the most likely implementation - it also matches = how e.g. the CDG TCP congestion control mechanism (which was found to = exhibit LBE=E2=80=99 behaviour) works. The LBE stuff in minset comes = from the usage draft. > --- > Abort without delivering... >=20 > Abortis currently specified for SCTP and TCP. If one assumes the bound = semantics for UDP(Lite) this also seems also the correct primitive for = UDP(Lite. >=20 > Should this ID specify a connect primitive also for bound use of = UDP(Lite)? Okay, I think you found an error here: Both =E2=80=9Cconnect" and =E2=80=9Cclose" primitives exist in = draft-ietf-taps-transports-usage-udp, and were taken over into step 2 of = draft-ietf-taps-transports-usage. Step 3, which is where the transport = features in minset come from, misses UDP(-Lite) under =E2=80=9Cclose=E2=80= =9D ! As I was writing the more elaborate description of =E2=80=9Cclose=E2=80=9D= in step 3, "Close after reliably delivering all remaining data, causing = an event informing the application on the other side=E2=80=9D, I felt I = really couldn't place UDP(-Lite) there, I think this is how it was = dropped. UDP(-Lite) would have survived if this would have been called = =E2=80=9CABORT=E2=80=9D, and here=E2=80=99s the mistake: semantically, = as you identify here, UDP(-Lite)=E2=80=99s =E2=80=9Cclose=E2=80=9D is = really equivalent to =E2=80=9Cabort=E2=80=9D, not =E2=80=9Cclose=E2=80=9D.= I can fix this in the next update of the -usage draft, and adjust the = -minset draft accordingly. > --- >=20 > What should be said about SCTP usage of IP OPTIONS? I would have = expected if the endpoint network layer set these, they would also work = for SCTP? Look for =E2=80=9CSET_IP_OPTIONS=E2=80=9D in = draft-ietf-taps-transports-usage-udp: your text here cites RFC 1122 = saying that UDP offers access to this functionality. I haven=E2=80=99t = found anything equivalent for SCTP. It may exist in implementations? = I=E2=80=99m not sure how this is done - maybe there=E2=80=99s a general = call to configure IP options for all outgoing packets on an interface, = or to a certain destination? If so, this would be worth pointing out at = this point, when it comes to discussing possible fall-backs. > --- >=20 > Finally, >=20 > I think I can agree the argument that UDP(Lite) message handling is = different to SCTP. >=20 > --- >=20 > Gorry Thanks again! Cheers, Michael From nobody Sun Mar 26 04:19:16 2017 Return-Path: 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 C44F6126C3D for ; Sun, 26 Mar 2017 04:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ka2W4dqZoXpB for ; Sun, 26 Mar 2017 04:19:13 -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 CC3F41243FE for ; Sun, 26 Mar 2017 04:19:12 -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 ) id 1cs6CV-0004sZ-7g; Sun, 26 Mar 2017 13:19:11 +0200 Received: from swissotel07.s.subnet.rcn.com ([216.80.61.6] helo=[172.20.3.190]) 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 ) id 1cs6CU-0007YY-7K; Sun, 26 Mar 2017 13:19:11 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Michael Welzl In-Reply-To: Date: Sun, 26 Mar 2017 06:19:09 -0500 Cc: Stein Gjessing , "taps@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <58D51F35.5020209@erg.abdn.ac.uk> To: " Fairhurst" X-Mailer: Apple Mail (2.3259) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx02.uio.no: 216.80.61.6 is neither permitted nor denied by domain of ifi.uio.no) client-ip=216.80.61.6; envelope-from=michawe@ifi.uio.no; helo=[172.20.3.190]; X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 2 sum rcpts/h 12 sum msgs/h 4 total rcpts 53196 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 22C791A32C6EB04093710AA1B33C9E870E428BD4 X-UiO-SPAM-Test: remote_host: 216.80.61.6 spam_score: -49 maxlevel 80 minaction 1 bait 0 mail/h: 2 total 15 max/h 7 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [Taps] Comments on draft-gjessing-taps-minset-02 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Mar 2017 11:19:15 -0000 Ahh, sorry, no =E2=80=A6 I ALWAYS try to carefully check everything and = THEN a thought appears immediately after pressing the =E2=80=9Csend=E2=80=9D= button. About aborting vs. closing: >> --- >> Abort without delivering... >>=20 >> Abortis currently specified for SCTP and TCP. If one assumes the = bound semantics for UDP(Lite) this also seems also the correct primitive = for UDP(Lite. >>=20 >> Should this ID specify a connect primitive also for bound use of = UDP(Lite)? >=20 > Okay, I think you found an error here: > Both =E2=80=9Cconnect" and =E2=80=9Cclose" primitives exist in = draft-ietf-taps-transports-usage-udp, and were taken over into step 2 of = draft-ietf-taps-transports-usage. Step 3, which is where the transport = features in minset come from, misses UDP(-Lite) under =E2=80=9Cclose=E2=80= =9D ! > As I was writing the more elaborate description of =E2=80=9Cclose=E2=80=9D= in step 3, "Close after reliably delivering all remaining data, causing = an event informing the application on the other side=E2=80=9D, I felt I = really couldn't place UDP(-Lite) there, I think this is how it was = dropped. UDP(-Lite) would have survived if this would have been called = =E2=80=9CABORT=E2=80=9D, and here=E2=80=99s the mistake: semantically, = as you identify here, UDP(-Lite)=E2=80=99s =E2=80=9Cclose=E2=80=9D is = really equivalent to =E2=80=9Cabort=E2=80=9D, not =E2=80=9Cclose=E2=80=9D.= I can fix this in the next update of the -usage draft, and adjust the = -minset draft accordingly. What I just wrote here about being semantically equivalent to abort is = wrong. The full description of abort, in step 3 of the usage draft, is: "Abort without delivering remaining data, causing an event informing the = application on the other side" UDP(-Lite) doesn=E2=80=99t inform the application on the other side. I = guess we should give it a new name (=E2=80=9CAbort without delivering = remaining data, without causing an event informing the application on = the other side=E2=80=9D) and then process it in -minset like we = processed all the others. Cheers, Michael From nobody Sun Mar 26 10:13:57 2017 Return-Path: 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 EAEE21270A7 for ; Sun, 26 Mar 2017 10:13:55 -0700 (PDT) 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, RP_MATCHES_RCVD=-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 SfDE45omU1Xu for ; Sun, 26 Mar 2017 10:13:53 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id E38851200FC for ; Sun, 26 Mar 2017 10:13:52 -0700 (PDT) Received: from [172.31.98.95] (unknown [4.15.252.171]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 6B8451B015A2; Sun, 26 Mar 2017 20:11:27 +0100 (BST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: "Gorry (erg)" X-Mailer: iPhone Mail (14D27) In-Reply-To: Date: Sun, 26 Mar 2017 12:13:46 -0500 Cc: "taps@ietf.org" , Stein Gjessing Content-Transfer-Encoding: quoted-printable Message-Id: <3412A264-EA87-4619-B27F-49320E52F9BE@erg.abdn.ac.uk> References: <58D51F35.5020209@erg.abdn.ac.uk> To: Michael Welzl Archived-At: Subject: Re: [Taps] Comments on draft-gjessing-taps-minset-02 - just DSCP X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Mar 2017 17:13:56 -0000 This reply is just about the DSCP and QoS.=20 Everything you say about TAPS trying to set DSCP values seems consistent wi= th normal diffserv use to me: Just because an app sets a DSCP does not mean t= he actually sent packets are assigned a PHB along the path, it simply marks t= hem for this treatment, and packets may also be remarked or dropped. Since t= here are no guarentees, there is no need for a primitive telling an app it d= id not get what it hoped for. So to me, this is normal Diffserv QoS treatmen= t. No guarentees. The words in the charter say " Signaling-based Quality-of-Service (QoS) mechanisms" --- which sounds like a= plea not to redesign NSIS RSVP etc... Gorry On 26 Mar 2017, at 06:14, Michael Welzl wrote: >> I see phrase: >> " Because QoS is out of scope of TAPS, this document assumes a "best >> effort" service model [RFC5290], [RFC7305]. " >>=20 >> I'm not sure we need to state this. Although I agree that TAPS will not p= ropose new QoS techniques, the service provided by TAPS is, I think, also no= t confined to "best effort=E2=80=9D. >=20 > Hmm... I was also thinking about the behavior of the actual TAPS system in= the end host, where you may ask for something but might not get it (e.g. re= quested unordered message delivery might turn into ordered bytestream delive= ry). > So for now, best effort is indeed the underlying assumption - e.g. the pro= posed =E2=80=9Ccapacity profile=E2=80=9D doesn=E2=80=99t come with any guara= ntees, it *might* set the DSCP for you, and that *might* have a certain effe= ct. > If we take that assumption away, the proposed system would be different - i= t would have to fail and say =E2=80=9Cno, sorry=E2=80=9D more often, which I= don=E2=80=99t think is a good way ahead. What do you think? >=20 From nobody Sun Mar 26 11:59:45 2017 Return-Path: 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 F3590129487 for ; Sun, 26 Mar 2017 11:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 JHT3weqoaXeg for ; Sun, 26 Mar 2017 11:59:37 -0700 (PDT) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (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 0511F129681 for ; Sun, 26 Mar 2017 11:59:37 -0700 (PDT) Received: from mail-mx05.uio.no ([129.240.10.49]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1csDO3-0000S2-D9; Sun, 26 Mar 2017 20:59:35 +0200 Received: from swissotel07.s.subnet.rcn.com ([216.80.61.6] helo=[172.20.3.190]) by mail-mx05.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1csDO2-000Fr3-Rd; Sun, 26 Mar 2017 20:59:35 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Michael Welzl In-Reply-To: <3412A264-EA87-4619-B27F-49320E52F9BE@erg.abdn.ac.uk> Date: Sun, 26 Mar 2017 13:59:32 -0500 Cc: "taps@ietf.org" , Stein Gjessing Content-Transfer-Encoding: quoted-printable Message-Id: <928FA176-01B2-426A-8702-2DF65BBFD3A3@ifi.uio.no> References: <58D51F35.5020209@erg.abdn.ac.uk> <3412A264-EA87-4619-B27F-49320E52F9BE@erg.abdn.ac.uk> To: " Fairhurst" X-Mailer: Apple Mail (2.3259) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx05.uio.no: 216.80.61.6 is neither permitted nor denied by domain of ifi.uio.no) client-ip=216.80.61.6; envelope-from=michawe@ifi.uio.no; helo=[172.20.3.190]; X-UiO-Ratelimit-Test: rcpts/h 11 msgs/h 5 sum rcpts/h 13 sum msgs/h 6 total rcpts 53219 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-4.9, required=5.0, autolearn=disabled, AWL=0.109, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 133A11BA73AC7549CDAC46F57A11B7505A35E1DC X-UiO-SPAM-Test: remote_host: 216.80.61.6 spam_score: -48 maxlevel 80 minaction 1 bait 0 mail/h: 5 total 32 max/h 7 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [Taps] Comments on draft-gjessing-taps-minset-02 - just DSCP X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Mar 2017 18:59:44 -0000 > On Mar 26, 2017, at 12:13 PM, Gorry (erg) = wrote: >=20 >=20 > This reply is just about the DSCP and QoS.=20 >=20 > Everything you say about TAPS trying to set DSCP values seems = consistent with normal diffserv use to me: Just because an app sets a = DSCP does not mean the actually sent packets are assigned a PHB along = the path, it simply marks them for this treatment, and packets may also = be remarked or dropped. Since there are no guarentees, there is no need = for a primitive telling an app it did not get what it hoped for. So to = me, this is normal Diffserv QoS treatment. No guarentees. But not even guaranteeing that packets will be marked would go to far? = Or wouldn=E2=80=99t it? (Just checking - because I think we could make the system guarantee = that, as all transports allow setting the DSCP; it was just my decision = to combine DSCP-setting with a few other things together and call them = "capacity profile", but that=E2=80=99s certainly up for debate). > The words in the charter say " > Signaling-based Quality-of-Service (QoS) mechanisms" --- which sounds = like a plea not to redesign NSIS RSVP etc=E2=80=A6 That would be my interpretation too. Cheers, Michael From nobody Sun Mar 26 18:21:19 2017 Return-Path: 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 B463412894E for ; Sun, 26 Mar 2017 18:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 PYGb_qYPiYPJ for ; Sun, 26 Mar 2017 18:21:16 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id D08EC127097 for ; Sun, 26 Mar 2017 18:21:15 -0700 (PDT) Received: from Gs-MacBook-Pro.local (unknown [216.80.70.251]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 72A1A1B01772 for ; Mon, 27 Mar 2017 04:18:38 +0100 (BST) Message-ID: <58D868FE.4080305@erg.abdn.ac.uk> Date: Sun, 26 Mar 2017 20:21:02 -0500 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: taps@ietf.org References: <58D51F35.5020209@erg.abdn.ac.uk> <3412A264-EA87-4619-B27F-49320E52F9BE@erg.abdn.ac.uk> <928FA176-01B2-426A-8702-2DF65BBFD3A3@ifi.uio.no> In-Reply-To: <928FA176-01B2-426A-8702-2DF65BBFD3A3@ifi.uio.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Taps] Comments on draft-gjessing-taps-minset-02 - just DSCP X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 01:21:18 -0000 On 26/03/2017, 13:59, Michael Welzl wrote: >> On Mar 26, 2017, at 12:13 PM, Gorry (erg) wrote: >> >> >> This reply is just about the DSCP and QoS. >> >> Everything you say about TAPS trying to set DSCP values seems consistent with normal diffserv use to me: Just because an app sets a DSCP does not mean the actually sent packets are assigned a PHB along the path, it simply marks them for this treatment, and packets may also be remarked or dropped. Since there are no guarentees, there is no need for a primitive telling an app it did not get what it hoped for. So to me, this is normal Diffserv QoS treatment. No guarentees. > But not even guaranteeing that packets will be marked would go to far? Or wouldn’t it? It clearly doen't help deploy diffserv if your local system bleaches the DCSP value to zero. That happens though. So we need to live with that. I'd therefore say it is OK. > (Just checking - because I think we could make the system guarantee that, as all transports allow setting the DSCP; it was just my decision to combine DSCP-setting with a few other things together and call them "capacity profile", but that’s certainly up for debate). > That's more interesting to debate. >> The words in the charter say " >> Signaling-based Quality-of-Service (QoS) mechanisms" --- which sounds like a plea not to redesign NSIS RSVP etc… > That would be my interpretation too. > > Cheers, > Michael > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps Gorry From nobody Mon Mar 27 16:36:04 2017 Return-Path: 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 0F07D1295E3 for ; Mon, 27 Mar 2017 16:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 TMc-HEtncmuc for ; Mon, 27 Mar 2017 16:36:00 -0700 (PDT) Received: from tiger.dc.kau.se (smtp.kau.se [193.10.220.38]) (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 06CDA12963D for ; Mon, 27 Mar 2017 16:35:57 -0700 (PDT) X-Spam-Processed: mail.kau.se, Tue, 28 Mar 2017 01:35:49 +0200 (not processed: spam filter heuristic analysis disabled) X-MDRemoteIP: 213.113.182.104 X-MDArrival-Date: Tue, 28 Mar 2017 01:35:49 +0200 X-Authenticated-Sender: anna.brunstrom@kau.se X-Return-Path: anna.brunstrom@kau.se X-Envelope-From: anna.brunstrom@kau.se To: Joe Touch , "taps@ietf.org" References: <148942913904.9187.9087920412455130356.idtracker@ietfa.amsl.com> <9fcb9fc9-4cd9-38e7-c51c-d376f01b933d@kau.se> <71f52e2e-c156-bfad-488d-f88e83cde141@isi.edu> From: Anna Brunstrom Message-ID: Date: Tue, 28 Mar 2017 01:35:47 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <71f52e2e-c156-bfad-488d-f88e83cde141@isi.edu> Content-Type: multipart/alternative; boundary="------------290BFF97F0CFD81D500213AE" Archived-At: Subject: Re: [Taps] Fwd: New Version Notification for draft-grinnemo-taps-he-02.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 23:36:03 -0000 This is a multi-part message in MIME format. --------------290BFF97F0CFD81D500213AE Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Joe, Thanks for your comments! On 2017-03-21 23:41, Joe Touch wrote: > > Hi, all, > > Some observations: > > - HE-trans MUST NOT be used to try different combinations of options > within a given transport > Sounds reasonable, trying out options is not the target here. Not sure if options even need to be discussed in the draft. > - I'm wondering about the potential for problems when ports are reused > between different attempts, e.g., IPv6-TCP then IPv4-TCP This should be the same as for RFC6555, so I do not think any new problems in relation to port reuse are introduced. > - the document works only for connection-orient transports that treat > failed connections as "no information" > > if a connection fails for other reasons, the origin might receive > an ICMP message that prohibits further attempts, either to that > transport, port, or address > > if a connection attempt is rejected but used as information, you > could end up with confusing results (e.g., as a covert channel) > > in that case, you're not doing HE; IMO, HE requires that there be > no impact to failed attempts > I do not follow this argument. Why does HE require that there be no impact to failed attempts? I think caching of failed connection attempts is important to reduce network load. RFC6555 also requires that the client MUST cache information regarding the outcome of each connection attempt, so the same principle should be followed here I think. Thanks again for your comments, Anna > Joe > > > On 3/14/2017 2:37 AM, Anna Brunstrom wrote: >> >> Hi all, >> >> The draft below on happy eyeballs was submitted last night. It is on >> the agenda for Chicago, but we are happy to hear any comments you may >> have also before then. >> >> Cheers, >> Anna >> >> -------- Forwarded Message -------- >> Subject: New Version Notification for draft-grinnemo-taps-he-02.txt >> Date: Mon, 13 Mar 2017 11:18:59 -0700 >> From: internet-drafts@ietf.org >> To: Zdravko Bozakov , Zdravko Bozakov >> , Anna Brunstrom , >> Per Hurtig , Karl-Johan Grinnemo >> , Naeem Khademi >> >> >> >> A new version of I-D, draft-grinnemo-taps-he-02.txt >> has been successfully submitted by Karl-Johan Grinnemo and posted to the >> IETF repository. >> >> Name: draft-grinnemo-taps-he >> Revision: 02 >> Title: Happy Eyeballs for Transport Selection >> Document date: 2017-03-13 >> Group: Individual Submission >> Pages: 10 >> URL:https://www.ietf.org/internet-drafts/draft-grinnemo-taps-he-02.txt >> Status:https://datatracker.ietf.org/doc/draft-grinnemo-taps-he/ >> Htmlized:https://tools.ietf.org/html/draft-grinnemo-taps-he-02 >> Diff:https://www.ietf.org/rfcdiff?url2=draft-grinnemo-taps-he-02 >> >> Abstract: >> Ideally, network applications should be able to select an appropriate >> transport solution from among available transport solutions. >> However, at present, there is no agreed-upon way to do this. In >> fact, there is not even an agreed-upon way for a source end host to >> determine if there is support for a particular transport along a >> network path. This draft addresses these issues, by proposing a >> Happy Eyeballs framework. The proposed Happy Eyeballs framework >> enables the selection of a transport solution that according to >> application requirements, pre-set policies, and estimated network >> conditions is the most appropriate one. Additionally, the proposed >> framework makes it possible for an application to find out whether a >> particular transport is supported along a network connection towards >> a specific destination or not. >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps > --------------290BFF97F0CFD81D500213AE Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hi Joe,

Thanks for your comments!

On 2017-03-21 23:41, Joe Touch wrote:

Hi, all,

Some observations:

- HE-trans MUST NOT be used to try different combinations of options within a given transport


Sounds reasonable, trying out options is not the target here. Not sure if options even need to be discussed in the draft.

- I'm wondering about the potential for problems when ports are reused between different attempts, e.g., IPv6-TCP then IPv4-TCP

This should be the same as for RFC6555, so I do not think any new problems in relation to port reuse are introduced.

- the document works only for connection-orient transports that treat failed connections as "no information"

    if a connection fails for other reasons, the origin might receive an ICMP message that prohibits further attempts, either to that transport, port, or address

    if a connection attempt is rejected but used as information, you could end up with confusing results (e.g., as a covert channel)

    in that case, you're not doing HE; IMO, HE requires that there be no impact to failed attempts


I do not follow this argument. Why does HE require that there be no impact to failed attempts? I think caching of failed connection attempts is important to reduce network load. RFC6555 also requires that the client MUST cache information regarding the outcome of each connection attempt, so the same principle should be followed here I think.

Thanks again for your comments,
Anna

Joe


On 3/14/2017 2:37 AM, Anna Brunstrom wrote:

Hi all,

The draft below on happy eyeballs was submitted last night. It is on the agenda for Chicago, but we are happy to hear any comments you may have also before then.

Cheers,
Anna

-------- Forwarded Message --------
Subject: New Version Notification for draft-grinnemo-taps-he-02.txt
Date: Mon, 13 Mar 2017 11:18:59 -0700
From: internet-drafts@ietf.org
To: Zdravko Bozakov <Zdravko.Bozakov@dell.com>, Zdravko Bozakov <zdravko.bozakov@dell.com>, Anna Brunstrom <anna.brunstrom@kau.se>, Per Hurtig <per.hurtig@kau.se>, Karl-Johan Grinnemo <karl-johan.grinnemo@kau.se>, Naeem Khademi <naeemk@ifi.uio.no> 


A new version of I-D, draft-grinnemo-taps-he-02.txt
has been successfully submitted by Karl-Johan Grinnemo and posted to the
IETF repository.

Name:		draft-grinnemo-taps-he
Revision:	02
Title:		Happy Eyeballs for Transport Selection
Document date:	2017-03-13
Group:		Individual Submission
Pages:		10
URL:            https://www.ietf.org/internet-drafts/draft-grinnemo-taps-he-02.txt
Status:         https://datatracker.ietf.org/doc/draft-grinnemo-taps-he/
Htmlized:       https://tools.ietf.org/html/draft-grinnemo-taps-he-02
Diff:           https://www.ietf.org/rfcdiff?url2=draft-grinnemo-taps-he-02

Abstract:
   Ideally, network applications should be able to select an appropriate
   transport solution from among available transport solutions.
   However, at present, there is no agreed-upon way to do this.  In
   fact, there is not even an agreed-upon way for a source end host to
   determine if there is support for a particular transport along a
   network path.  This draft addresses these issues, by proposing a
   Happy Eyeballs framework.  The proposed Happy Eyeballs framework
   enables the selection of a transport solution that according to
   application requirements, pre-set policies, and estimated network
   conditions is the most appropriate one.  Additionally, the proposed
   framework makes it possible for an application to find out whether a
   particular transport is supported along a network connection towards
   a specific destination or not.

                                                                                  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps


--------------290BFF97F0CFD81D500213AE-- From nobody Mon Mar 27 20:46:03 2017 Return-Path: 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 21DB9129432 for ; Mon, 27 Mar 2017 20:46:01 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 9sqakvZ6__9E for ; Mon, 27 Mar 2017 20:45:58 -0700 (PDT) Received: from mail-in24.apple.com (mail-out24.apple.com [17.171.2.34]) (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 88D7B12922E for ; Mon, 27 Mar 2017 20:45:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1490672756; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ZtDZfgD5Ob7XyZyh+DmS168g/oJ6DIAh1IUUPGdxvBg=; b=tXrVWYbBnIy8/ZNMAmeg1FYVE5BmKx8knRClQxb7FTti1gdHL2Bwrr6LgkJjvpGx oajCZawMwTeA1PU9MMM8BlA39VlpTxnBifdwQgpQd0V0OycbXYgo6yY7htRNqN1c wl1vRpaenznNa9Sdc3dTsyXv8YXbwRwvZByc0+xmMaUx1Wi6nh3RfsZawil8Wr/m j/PdJjMqCMdLbQ5K4v5jQL8CdPR36MwRZhiV7U5+L0o/yWWebwgkUUSRpHGi35AD SAdUnuCCSf0wHhYVNg6ArALPpd3d6oxOCgWbyiPkABrTgTKKwmlt/eznAfsZ8OHX UVu4ZtF07dbFIOuh/1b1kA==; Received: from relay23.apple.com (relay23.apple.com [17.171.128.104]) by mail-in24.apple.com (Apple Secure Mail Relay) with SMTP id 96.C3.01216.47CD9D85; Mon, 27 Mar 2017 20:45:56 -0700 (PDT) X-AuditID: 11ab0218-d65fb700000004c0-a5-58d9dc74e2f3 Received: from ma1-mmpp-sz10.apple.com (st1-02-mail-lb2-v365-snip.apple.com [17.171.128.5]) by relay23.apple.com (Apple SCV relay) with SMTP id 97.A8.24250.37CD9D85; Mon, 27 Mar 2017 23:45:56 -0400 (EDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_TElHj/PvsFmcdfnLNaag1w)" Received: from [17.168.167.160] by ma1-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0ONI00M9IAF8QH70@ma1-mmpp-sz10.apple.com>; Mon, 27 Mar 2017 20:45:55 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: Date: Mon, 27 Mar 2017 22:45:55 -0500 In-reply-to: Cc: Joe Touch , "taps@ietf.org" To: Anna Brunstrom References: <148942913904.9187.9087920412455130356.idtracker@ietfa.amsl.com> <9fcb9fc9-4cd9-38e7-c51c-d376f01b933d@kau.se> <71f52e2e-c156-bfad-488d-f88e83cde141@isi.edu> X-Mailer: Apple Mail (2.3263) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDLMWRmVeSWpSXmKPExsUiuLohQ7fkzs0IgzN7jSxO/LjMbHEnxmLd n7ksDsweS5b8ZPLY/X4ri8ffC61sAcxRXDYpqTmZZalF+nYJXBkH3s9hKpjdyVgx869dA+PU vC5GDg4JAROJt+9Kuxi5OIQEDjJK/L7SydbFyAkWn9XTwAKROMsoMfvbREaQBK+AoMSPyfdY QGxmgTCJU0s3MEEUfWOUmHxmORPIVGEBCYnNexJBatgEVCSOf9vADNFrI7Hj93awOcICfhIz D85nB7FZBFQlHvYtBZvJKWAl8W3pI6j5dhIn9p1jArFFBLQkJtxqZofYdZdRYsOiMywQl8pK dC+cxgySkBBYwyax6M4clgmMQrOQHDsLybEQtpbE90etQHEOIFte4uB5WYiwpsSze5/YIWxt iSfvLrAuYGRbxSicm5iZo5uZZ2Sil1hQkJOql5yfu4kRHB1MEjsYv7w2PMQowMGoxMN7gedm hBBrYllxZe4hRmkOFiVx3t85QCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MB+WVzrOnTM// +vulueCPFSb+IdUnw1pjW04sEtbOjvTccOS1o53BIvEtGUyR+1yt8llU+JpCLxroWGtl8Dpf yPi3dvFBp55ET/0c9XJdq9cru+W/us/vapmu3LZYudJN466BkaDUuQzlQ26/756529wgIsZ+ Ybfe8luOvJ0fbkx+tM/p5UolluKMREMt5qLiRACZ+ggUbwIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUiuLqBVbfkzs0Ig9adTBYnflxmtrgTY7Hu z1wWB2aPJUt+Mnnsfr+VxePvhVa2AOYoLpuU1JzMstQifbsErowD7+cwFczuZKyY+deugXFq XhcjJ4eEgInErJ4Gli5GLg4hgbOMErO/TWQESfAKCEr8mHyPBcRmFgiTOLV0AxNE0TdGicln lgM5HBzCAhISm/ckgtSwCahIHP+2gRmi10Zix+/tYHOEBfwkZh6czw5iswioSjzsWwo2k1PA SuLb0kdQ8+0kTuw7xwRiiwhoSUy41cwOsesuo8SGRWdYIC6VleheOI15AiP/LCT3zUJyH4St JfH9UStQnAPIlpc4eF4WIqwp8ezeJ3YIW1viybsLrAsY2VYxChal5iRWGhnrJRYU5KTqJefn bmKEhHPGDsbrN80OMQpwMCrx8FZw3YwQYk0sK67MPcQowcGsJML7pBUoxJuSWFmVWpQfX1Sa k1p8iFGag0VJnPfl10sRQgLpiSWp2ampBalFMFkmDk6pBkbRk9d3Ca1+pLP+l0vv3cyHS+Oi DXZY/4m9bau0Oc588nxJ7hy5/5+CduWdzGw4zu1XcO8OjyPfXT6/q0XchVb/9dex3dF/V93P tcJLsE5zQ+fXJVn/mG0U9hj8rFxVFdLxaPXLvf+WTZ3lO9GIZd7y7WsWNfy/pHX4lc1y6YSJ /+3ur4vN+2CvxFKckWioxVxUnAgAVw8LRWMCAAA= Archived-At: Subject: Re: [Taps] New Version Notification for draft-grinnemo-taps-he-02.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 03:46:01 -0000 --Boundary_(ID_TElHj/PvsFmcdfnLNaag1w) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT > On Mar 27, 2017, at 6:35 PM, Anna Brunstrom wrote: > > Hi Joe, > > Thanks for your comments! > On 2017-03-21 23:41, Joe Touch wrote: >> Hi, all, >> >> Some observations: >> >> - HE-trans MUST NOT be used to try different combinations of options within a given transport >> > > Sounds reasonable, trying out options is not the target here. Not sure if options even need to be discussed in the draft. > >> - I'm wondering about the potential for problems when ports are reused between different attempts, e.g., IPv6-TCP then IPv4-TCP > > This should be the same as for RFC6555, so I do not think any new problems in relation to port reuse are introduced. > >> - the document works only for connection-orient transports that treat failed connections as "no information" >> >> if a connection fails for other reasons, the origin might receive an ICMP message that prohibits further attempts, either to that transport, port, or address >> >> if a connection attempt is rejected but used as information, you could end up with confusing results (e.g., as a covert channel) >> in that case, you're not doing HE; IMO, HE requires that there be no impact to failed attempts >> > > I do not follow this argument. Why does HE require that there be no impact to failed attempts? I think caching of failed connection attempts is important to reduce network load. RFC6555 also requires that the client MUST cache information regarding the outcome of each connection attempt, so the same principle should be followed here I think. I think there are two separate cases here: - If the client that is initiating the protocol attempts is using a protocol for which a failed attempt causes it to throw an error/exception, then the act of racing will have a negative impact on the client. - If, instead, the client simply uses the failed attempt as historical information to inform future policy, then that is very much in line with RFC 6555, Section 4.2 It would be useful to clarify in the document that the only protocols which can be meaningfully raced via any mechanism are those that have a notion of becoming "connected" or "established" that does not correspond to simply sending the first bit of data. UDP and traditionally 'connectionless' protocols can have some overlay of what it means to be 'connected' to cut off the race, or else they form the degenerate case in which the race it cut off immediately once a connection attempt is started. Thanks, Tommy > > Thanks again for your comments, > Anna > >> Joe >> >> On 3/14/2017 2:37 AM, Anna Brunstrom wrote: >>> Hi all, >>> >>> The draft below on happy eyeballs was submitted last night. It is on the agenda for Chicago, but we are happy to hear any comments you may have also before then. >>> Cheers, >>> Anna >>> >>> -------- Forwarded Message -------- >>> Subject: New Version Notification for draft-grinnemo-taps-he-02.txt >>> Date: Mon, 13 Mar 2017 11:18:59 -0700 >>> From: internet-drafts@ietf.org >>> To: Zdravko Bozakov , Zdravko Bozakov , Anna Brunstrom , Per Hurtig , Karl-Johan Grinnemo , Naeem Khademi >>> >>> A new version of I-D, draft-grinnemo-taps-he-02.txt >>> has been successfully submitted by Karl-Johan Grinnemo and posted to the >>> IETF repository. >>> >>> Name: draft-grinnemo-taps-he >>> Revision: 02 >>> Title: Happy Eyeballs for Transport Selection >>> Document date: 2017-03-13 >>> Group: Individual Submission >>> Pages: 10 >>> URL: https://www.ietf.org/internet-drafts/draft-grinnemo-taps-he-02.txt >>> Status: https://datatracker.ietf.org/doc/draft-grinnemo-taps-he/ >>> Htmlized: https://tools.ietf.org/html/draft-grinnemo-taps-he-02 >>> Diff: https://www.ietf.org/rfcdiff?url2=draft-grinnemo-taps-he-02 >>> >>> Abstract: >>> Ideally, network applications should be able to select an appropriate >>> transport solution from among available transport solutions. >>> However, at present, there is no agreed-upon way to do this. In >>> fact, there is not even an agreed-upon way for a source end host to >>> determine if there is support for a particular transport along a >>> network path. This draft addresses these issues, by proposing a >>> Happy Eyeballs framework. The proposed Happy Eyeballs framework >>> enables the selection of a transport solution that according to >>> application requirements, pre-set policies, and estimated network >>> conditions is the most appropriate one. Additionally, the proposed >>> framework makes it possible for an application to find out whether a >>> particular transport is supported along a network connection towards >>> a specific destination or not. >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> The IETF Secretariat >>> >>> >>> >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >> > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Boundary_(ID_TElHj/PvsFmcdfnLNaag1w) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable
On Mar 27, 2017, at 6:35 PM, Anna Brunstrom <anna.brunstrom@kau.se> wrote:

=20 =20

Hi = Joe,

Thanks for your comments!

On 2017-03-21 23:41, Joe Touch wrote:

Hi, all,

Some observations:

- HE-trans MUST NOT be = used to try different combinations of options within a given transport


Sounds reasonable, trying out options is not the target here. Not sure if options even need to be discussed in the draft.
=
- I'm wondering about the potential for = problems when ports are reused between different attempts, e.g., IPv6-TCP then IPv4-TCP

This should be the same as for RFC6555, so I do not think any new problems in relation to port reuse are introduced.

- the document works only for = connection-orient transports that treat failed connections as "no information"

    if a connection fails for other reasons, = the origin might receive an ICMP message that prohibits further attempts, either to that transport, port, or address

    if a connection attempt is rejected but = used as information, you could end up with confusing results (e.g., as a covert channel)

    in that case, you're not = doing HE; IMO, HE requires that there be no impact to failed attempts


I do not follow this argument. Why does HE require that there be no impact to failed attempts? I think caching of failed connection attempts is important to reduce network load. RFC6555 also requires that the client MUST cache information regarding the outcome of each connection attempt, so the same principle should be followed here I think.

I think there are two separate cases = here:

- If the client that is = initiating the protocol attempts is using a protocol for which a failed = attempt causes it to throw an error/exception, then the act of racing = will have a negative impact on the client. 
- If, = instead, the client simply uses the failed attempt as historical = information to inform future policy, then that is very much in line with = RFC 6555, Section 4.2

It would be = useful to clarify in the document that the only protocols which can be = meaningfully raced via any mechanism are those that have a notion of = becoming "connected" or "established" that does not correspond to simply = sending the first bit of data. UDP and traditionally 'connectionless' = protocols can have some overlay of what it means to be 'connected' to = cut off the race, or else they form the degenerate case in which the = race it cut off immediately once a connection attempt is = started.

Thanks,
Tommy


Thanks again for your comments,
Anna

Joe


On 3/14/2017 2:37 AM, Anna = Brunstrom wrote:

Hi all,

The draft below on happy eyeballs was submitted last night. It is on the agenda for Chicago, but we are happy to hear any comments you may have also before then.

Cheers,
Anna

-------- Forwarded Message -------- =
Subject: New Version Notification for draft-grinnemo-taps-he-02.txt
Date: Mon, 13 Mar 2017 11:18:59 -0700
From: internet-drafts@ietf.org
To: Zdravko Bozakov <Zdravko.Bozakov@dell.com><= /a>, Zdravko Bozakov <zdravko.bozakov@dell.com><= /a>, Anna Brunstrom <anna.brunstrom@kau.se>, Per Hurtig <per.hurtig@kau.se>, Karl-Johan Grinnemo <karl-johan.grinnemo@kau.se&= gt;, Naeem Khademi <naeemk@ifi.uio.no> 


A new version of I-D, =
draft-grinnemo-taps-he-02.txt
has been successfully submitted by Karl-Johan Grinnemo and posted to the
IETF repository.

Name:		draft-grinnemo-taps-he
Revision:	02
Title:		Happy Eyeballs for Transport Selection
Document date:	2017-03-13
Group:		Individual Submission
Pages:		10
URL:            https://www.ietf.org/internet-drafts/draft-grinnemo-taps-he-02.txt
Status:         https://=
datatracker.ietf.org/doc/draft-grinnemo-taps-he/
Htmlized:       https://too=
ls.ietf.org/html/draft-grinnemo-taps-he-02
Diff:           htt=
ps://www.ietf.org/rfcdiff?url2=3Ddraft-grinnemo-taps-he-02

Abstract:
   Ideally, network applications should be able to select an appropriate
   transport solution from among available transport solutions.
   However, at present, there is no agreed-upon way to do this.  In
   fact, there is not even an agreed-upon way for a source end host to
   determine if there is support for a particular transport along a
   network path.  This draft addresses these issues, by proposing a
   Happy Eyeballs framework.  The proposed Happy Eyeballs framework
   enables the selection of a transport solution that according to
   application requirements, pre-set policies, and estimated network
   conditions is the most appropriate one.  Additionally, the proposed
   framework makes it possible for an application to find out whether a
   particular transport is supported along a network connection towards
   a specific destination or not.

                                                                         =
        =20


Please note that it may take a couple of minutes from the time of =
submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/m=
ailman/listinfo/taps


_______________________________________________
Taps = mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

= --Boundary_(ID_TElHj/PvsFmcdfnLNaag1w)-- From nobody Mon Mar 27 23:40:50 2017 Return-Path: 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 BA86F1296A6 for ; Mon, 27 Mar 2017 23:40:48 -0700 (PDT) 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, HTML_MESSAGE=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 DtuxYMxIp_Nk for ; Mon, 27 Mar 2017 23:40:45 -0700 (PDT) Received: from tiger.dc.kau.se (smtp.kau.se [193.10.220.38]) (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 60A2B126C89 for ; Mon, 27 Mar 2017 23:40:45 -0700 (PDT) X-Spam-Processed: mail.kau.se, Tue, 28 Mar 2017 08:40:37 +0200 (not processed: spam filter heuristic analysis disabled) X-MDRemoteIP: 193.10.220.169 X-MDArrival-Date: Tue, 28 Mar 2017 08:40:37 +0200 X-Authenticated-Sender: anna.brunstrom@kau.se X-Return-Path: anna.brunstrom@kau.se X-Envelope-From: anna.brunstrom@kau.se To: Tommy Pauly References: <148942913904.9187.9087920412455130356.idtracker@ietfa.amsl.com> <9fcb9fc9-4cd9-38e7-c51c-d376f01b933d@kau.se> <71f52e2e-c156-bfad-488d-f88e83cde141@isi.edu> Cc: Joe Touch , "taps@ietf.org" From: Anna Brunstrom Message-ID: <6d65403c-1647-1351-c0db-dc4e5fa563fe@kau.se> Date: Tue, 28 Mar 2017 08:40:38 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------141776B1E74F175CD7C1881C" Archived-At: Subject: Re: [Taps] New Version Notification for draft-grinnemo-taps-he-02.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 06:40:49 -0000 This is a multi-part message in MIME format. --------------141776B1E74F175CD7C1881C Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Tommy, On 2017-03-28 05:45, Tommy Pauly wrote: > >> On Mar 27, 2017, at 6:35 PM, Anna Brunstrom > > wrote: >> >> Hi Joe, >> >> Thanks for your comments! >> >> On 2017-03-21 23:41, Joe Touch wrote: >>> >>> Hi, all, >>> >>> Some observations: >>> >>> - HE-trans MUST NOT be used to try different combinations of options >>> within a given transport >>> >> >> Sounds reasonable, trying out options is not the target here. Not >> sure if options even need to be discussed in the draft. >> >>> - I'm wondering about the potential for problems when ports are >>> reused between different attempts, e.g., IPv6-TCP then IPv4-TCP >> >> This should be the same as for RFC6555, so I do not think any new >> problems in relation to port reuse are introduced. >> >>> - the document works only for connection-orient transports that >>> treat failed connections as "no information" >>> >>> if a connection fails for other reasons, the origin might >>> receive an ICMP message that prohibits further attempts, either to >>> that transport, port, or address >>> >>> if a connection attempt is rejected but used as information, you >>> could end up with confusing results (e.g., as a covert channel) >>> >>> in that case, you're not doing HE; IMO, HE requires that there >>> be no impact to failed attempts >>> >> >> I do not follow this argument. Why does HE require that there be no >> impact to failed attempts? I think caching of failed connection >> attempts is important to reduce network load. RFC6555 also requires >> that the client MUST cache information regarding the outcome of each >> connection attempt, so the same principle should be followed here I >> think. > > I think there are two separate cases here: > > - If the client that is initiating the protocol attempts is using a > protocol for which a failed attempt causes it to throw an > error/exception, then the act of racing will have a negative impact on > the client. > - If, instead, the client simply uses the failed attempt as historical > information to inform future policy, then that is very much in line > with RFC 6555, Section 4.2 > > It would be useful to clarify in the document that the only protocols > which can be meaningfully raced via any mechanism are those that have > a notion of becoming "connected" or "established" that does not > correspond to simply sending the first bit of data. UDP and > traditionally 'connectionless' protocols can have some overlay of what > it means to be 'connected' to cut off the race, or else they form the > degenerate case in which the race it cut off immediately once a > connection attempt is started. > > Thanks, > Tommy Agreed. We will try to clarify this in the next version of the document. Thanks for your feedback! Anna > >> >> Thanks again for your comments, >> Anna >> >>> Joe >>> >>> >>> On 3/14/2017 2:37 AM, Anna Brunstrom wrote: >>>> >>>> Hi all, >>>> >>>> The draft below on happy eyeballs was submitted last night. It is >>>> on the agenda for Chicago, but we are happy to hear any comments >>>> you may have also before then. >>>> >>>> Cheers, >>>> Anna >>>> >>>> -------- Forwarded Message -------- >>>> Subject: New Version Notification for draft-grinnemo-taps-he-02.txt >>>> Date: Mon, 13 Mar 2017 11:18:59 -0700 >>>> From: internet-drafts@ietf.org >>>> To: Zdravko Bozakov , Zdravko Bozakov >>>> , Anna Brunstrom , >>>> Per Hurtig , Karl-Johan Grinnemo >>>> , Naeem Khademi >>>> >>>> >>>> >>>> A new version of I-D, draft-grinnemo-taps-he-02.txt >>>> has been successfully submitted by Karl-Johan Grinnemo and posted to the >>>> IETF repository. >>>> >>>> Name: draft-grinnemo-taps-he >>>> Revision: 02 >>>> Title: Happy Eyeballs for Transport Selection >>>> Document date: 2017-03-13 >>>> Group: Individual Submission >>>> Pages: 10 >>>> URL:https://www.ietf.org/internet-drafts/draft-grinnemo-taps-he-02.txt >>>> Status:https://datatracker.ietf.org/doc/draft-grinnemo-taps-he/ >>>> Htmlized:https://tools.ietf.org/html/draft-grinnemo-taps-he-02 >>>> Diff:https://www.ietf.org/rfcdiff?url2=draft-grinnemo-taps-he-02 >>>> >>>> Abstract: >>>> Ideally, network applications should be able to select an appropriate >>>> transport solution from among available transport solutions. >>>> However, at present, there is no agreed-upon way to do this. In >>>> fact, there is not even an agreed-upon way for a source end host to >>>> determine if there is support for a particular transport along a >>>> network path. This draft addresses these issues, by proposing a >>>> Happy Eyeballs framework. The proposed Happy Eyeballs framework >>>> enables the selection of a transport solution that according to >>>> application requirements, pre-set policies, and estimated network >>>> conditions is the most appropriate one. Additionally, the proposed >>>> framework makes it possible for an application to find out whether a >>>> particular transport is supported along a network connection towards >>>> a specific destination or not. >>>> >>>> >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of submission >>>> until the htmlized version and diff are available attools.ietf.org . >>>> >>>> The IETF Secretariat >>>> >>>> >>>> >>>> _______________________________________________ >>>> Taps mailing list >>>> Taps@ietf.org >>>> https://www.ietf.org/mailman/listinfo/taps >>> >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps > --------------141776B1E74F175CD7C1881C Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hi Tommy,


On 2017-03-28 05:45, Tommy Pauly wrote:


On Mar 27, 2017, at 6:35 PM, Anna Brunstrom <anna.brunstrom@kau.se> wrote:

Hi Joe,

Thanks for your comments!

On 2017-03-21 23:41, Joe Touch wrote:

Hi, all,

Some observations:

- HE-trans MUST NOT be used to try different combinations of options within a given transport


Sounds reasonable, trying out options is not the target here. Not sure if options even need to be discussed in the draft.

- I'm wondering about the potential for problems when ports are reused between different attempts, e.g., IPv6-TCP then IPv4-TCP

This should be the same as for RFC6555, so I do not think any new problems in relation to port reuse are introduced.

- the document works only for connection-orient transports that treat failed connections as "no information"

    if a connection fails for other reasons, the origin might receive an ICMP message that prohibits further attempts, either to that transport, port, or address

    if a connection attempt is rejected but used as information, you could end up with confusing results (e.g., as a covert channel)

    in that case, you're not doing HE; IMO, HE requires that there be no impact to failed attempts


I do not follow this argument. Why does HE require that there be no impact to failed attempts? I think caching of failed connection attempts is important to reduce network load. RFC6555 also requires that the client MUST cache information regarding the outcome of each connection attempt, so the same principle should be followed here I think.

I think there are two separate cases here:

- If the client that is initiating the protocol attempts is using a protocol for which a failed attempt causes it to throw an error/exception, then the act of racing will have a negative impact on the client. 
- If, instead, the client simply uses the failed attempt as historical information to inform future policy, then that is very much in line with RFC 6555, Section 4.2

It would be useful to clarify in the document that the only protocols which can be meaningfully raced via any mechanism are those that have a notion of becoming "connected" or "established" that does not correspond to simply sending the first bit of data. UDP and traditionally 'connectionless' protocols can have some overlay of what it means to be 'connected' to cut off the race, or else they form the degenerate case in which the race it cut off immediately once a connection attempt is started.

Thanks,
Tommy

Agreed. We will try to clarify this in the next version of the document.

Thanks for your feedback!
Anna



Thanks again for your comments,
Anna

Joe


On 3/14/2017 2:37 AM, Anna Brunstrom wrote:

Hi all,

The draft below on happy eyeballs was submitted last night. It is on the agenda for Chicago, but we are happy to hear any comments you may have also before then.

Cheers,
Anna

-------- Forwarded Message --------
Subject: New Version Notification for draft-grinnemo-taps-he-02.txt
Date: Mon, 13 Mar 2017 11:18:59 -0700
From: internet-drafts@ietf.org
To: Zdravko Bozakov <Zdravko.Bozakov@dell.com>, Zdravko Bozakov <zdravko.bozakov@dell.com>, Anna Brunstrom <anna.brunstrom@kau.se>, Per Hurtig <per.hurtig@kau.se>, Karl-Johan Grinnemo <karl-johan.grinnemo@kau.se>, Naeem Khademi <naeemk@ifi.uio.no> 


A new version of I-D, draft-grinnemo-taps-he-02.txt
has been successfully submitted by Karl-Johan Grinnemo and posted to the
IETF repository.

Name:		draft-grinnemo-taps-he
Revision:	02
Title:		Happy Eyeballs for Transport Selection
Document date:	2017-03-13
Group:		Individual Submission
Pages:		10
URL:            https://www.ietf.org/internet-drafts/draft-grinnemo-taps-he-02.txt
Status:         https://datatracker.ietf.org/doc/draft-grinnemo-taps-he/
Htmlized:       https://tools.ietf.org/html/draft-grinnemo-taps-he-02
Diff:           https://www.ietf.org/rfcdiff?url2=draft-grinnemo-taps-he-02

Abstract:
   Ideally, network applications should be able to select an appropriate
   transport solution from among available transport solutions.
   However, at present, there is no agreed-upon way to do this.  In
   fact, there is not even an agreed-upon way for a source end host to
   determine if there is support for a particular transport along a
   network path.  This draft addresses these issues, by proposing a
   Happy Eyeballs framework.  The proposed Happy Eyeballs framework
   enables the selection of a transport solution that according to
   application requirements, pre-set policies, and estimated network
   conditions is the most appropriate one.  Additionally, the proposed
   framework makes it possible for an application to find out whether a
   particular transport is supported along a network connection towards
   a specific destination or not.

                                                                                  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps


_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps


--------------141776B1E74F175CD7C1881C--