From nobody Wed May 18 04:47:37 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18E8212D0ED for ; Wed, 18 May 2016 04:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Sr26rAIg8BZg for ; Wed, 18 May 2016 04:47:32 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 77A3112D0EA for ; Wed, 18 May 2016 04:47:29 -0700 (PDT) Received: from 173.7.199.146.dyn.plus.net ([146.199.7.173]:37953 helo=[192.168.0.10]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1b2zwl-0007td-7Z for tcpPrague@ietf.org; Wed, 18 May 2016 12:47:27 +0100 To: TCP Prague List From: Bob Briscoe Message-ID: <573C564E.1090201@bobbriscoe.net> Date: Wed, 18 May 2016 12:47:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------020409070502060506090002" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: [tcpPrague] Volunteers pls: L4S non-WG-forming BoF proposal cut-off approaching X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 11:47:35 -0000 This is a multi-part message in MIME format. --------------020409070502060506090002 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Folks, At the Low Latency, Low Loss Scalable throughput (L4S) Bar Bof in Buenos Aires, there was support for a BoF about L4S, In the IETF-96 (Berlin) time-frame. It was decided to initially use this ML, even tho the scope of L4S is wider than TCP Prague. Consensus was to aim for a non-WG-forming BoF, to demonstrate willingness to work on the pieces in existing IETF WGs, and to co-ordinate approaches to each WG. The cut-off is now 2.5 weeks away. *2016-06-03 (Friday):* Cut-off date for BOF proposal requests to Area Directors at UTC 23:59. To organise a successful BoF (referring to rfc5434 ), we need volunteers for the following tasks: #/ Draft a statement of problem & scope #/ List planned deliverables (incl. implementation, spec drafting), milestones and target WG (also identify any critical interdependencies) #/ Identify and draft any necessary changes to WG charters, to cover the above deliverables #/ Discuss with relevant WG chairs and ADs [see background below] #/ Identify volunteers (pref before the BoF) planning to work on each deliverable Some people have already volunteered in general to help with arranging the BoF, but we now need to get specific. Let's get volunteers for the above priority tasks first, but for completeness I'll also list the formalities we have to do: #/ Decide on name of BoF (and mailing list) #/ BoF facilitators - chairs, scribes, etc #/ Draft the BoF agenda, incl. time constraints #/ Decide on the BoF questions #/ Estimate attendance, list conflicts, decide duration #/ Submit a formal request for the BoF via http://www.ietf.org/instructions/MTG-SLOTS.html and http://www.ietf.org/ietf/1bof-procedures.txt I'll start off co-ordinating and chasing all the above, but contact me if you would like to take on the co-ordinating task. *Background work so far** * The idea of this BoF has been floated with WG chairs and ADs for some time now (since Nov'15 in Yokohama), except AFAIK, we haven't talked with the RMCAT chairs. Also we have already done considerable work on defining the problem while writing various drafts and papers about L4S. But, that was just a small group of co-authors (me, Koen, Inton, Olga). There's still a lot to do to build wider consensus. We can go ahead with a BoF scheduling request even if disagreements on scope/problem remain. But before the BoF itself, we need to have any such disagreements ironed out. At the Buenos Aires Bar Bof, we put up a todo list of pieces that will need to be worked on: See http://www.bobbriscoe.net/presents/1604ietf/1604-l4s-bar-bof.pdf particularly slides 9 & 10 and the target WGs for each were: * TSVWG (the L4S identifier) * AQM (the AQM - the name gives the clue ;) * TCPM (the DCTCP-like congestion control, covering SCTP) * RMCAT (L4S variants of real-time congestion controls, or at least standardise existing controls using the identifier) I believe, formally, each WG has to decide to charter additional work on its own ML. [Since then, Ingemar has pointed out on this list that we also need to get AQM & ECN-marking in radio networks, and that will require working with/through other SDOs and/or developer groups that deal with the MAC layer . V. important, but let's push that to a separate thread.] Many of the pieces have their own rationale, independent of L4S. The idea of the BoF is to draw the bigger picture that motivates the work. That doesn't preclude incremental work on the pieces for those who are not motivated by a big picture. Cheers Bob -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------020409070502060506090002 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Folks,

At the Low Latency, Low Loss Scalable throughput (L4S) Bar Bof in Buenos Aires, there was support for a BoF about L4S, In the IETF-96 (Berlin) time-frame.
It was decided to initially use this ML, even tho the scope of L4S is wider than TCP Prague.
Consensus was to aim for a non-WG-forming BoF, to demonstrate willingness to work on the pieces in existing IETF WGs, and to co-ordinate approaches to each WG.

The cut-off is now 2.5 weeks away.
*2016-06-03 (Friday):* Cut-off date for BOF proposal requests to Area Directors at UTC 23:59.

To organise a successful BoF (referring to rfc5434), we need volunteers for the following tasks:
#/ Draft a statement of problem & scope
#/ List planned deliverables (incl. implementation, spec drafting), milestones and target WG (also identify any critical interdependencies)
#/ Identify and draft any necessary changes to WG charters, to cover the above deliverables
#/ Discuss with relevant WG chairs and ADs [see background below]
#/ Identify volunteers (pref before the BoF) planning to work on each deliverable

Some people have already volunteered in general to help with arranging the BoF, but we now need to get specific.

Let's get volunteers for the above priority tasks first, but for completeness I'll also list the formalities we have to do:
#/ Decide on name of BoF (and mailing list)
#/ BoF facilitators - chairs, scribes, etc
#/ Draft the BoF agenda, incl. time constraints
#/ Decide on the BoF questions
#/ Estimate attendance, list conflicts, decide duration
#/ Submit a formal request for the BoF via
     http://www.ietf.org/instructions/MTG-SLOTS.html and
     http://www.ietf.org/ietf/1bof-procedures.txt

I'll start off co-ordinating and chasing all the above, but contact me if you would like to take on the co-ordinating task.

Background work so far

The idea of this BoF has been floated with WG chairs and ADs for some time now (since Nov'15 in Yokohama), except AFAIK, we haven't talked with the RMCAT chairs.
Also we have already done considerable work on defining the problem while writing various drafts and papers about L4S.

But, that was just a small group of co-authors (me, Koen, Inton, Olga). There's still a lot to do to build wider consensus.
We can go ahead with a BoF scheduling request even if disagreements on scope/problem remain.
But before the BoF itself, we need to have any such disagreements ironed out.

At the Buenos Aires Bar Bof, we put up a todo list of pieces that will need to be worked on:
See http://www.bobbriscoe.net/presents/1604ietf/1604-l4s-bar-bof.pdf particularly slides 9 & 10
and the target WGs for each were:
* TSVWG (the L4S identifier)
* AQM (the AQM - the name gives the clue ;)
* TCPM (the DCTCP-like congestion control, covering SCTP)
* RMCAT (L4S variants of real-time congestion controls, or at least standardise existing controls using the identifier)

I believe, formally, each WG has to decide to charter additional work on its own ML.

[Since then, Ingemar has pointed out on this list that we also need to get AQM & ECN-marking in radio networks, and that will require working with/through other SDOs and/or developer groups that deal with the MAC layer .
V. important, but let's push that to a separate thread.]

Many of the pieces have their own rationale, independent of L4S. The idea of the BoF is to draw the bigger picture that motivates the work.
That doesn't preclude incremental work on the pieces for those who are not motivated by a big picture.

Cheers



Bob
-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------020409070502060506090002-- From nobody Wed May 18 07:54:33 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9775E12D16A for ; Wed, 18 May 2016 07:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mjmontpetit-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGbwCTR5gsrC for ; Wed, 18 May 2016 07:54:29 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 2E84312D164 for ; Wed, 18 May 2016 07:54:29 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id n62so25183306qkc.2 for ; Wed, 18 May 2016 07:54:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mjmontpetit-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=QQ79ZCKYvGOvnQSyLErq8PGgwi3KQrUbDd4skZCRZBM=; b=lR7xOrq6b4YJzzf01FkGbgjO/Zdd67fuIaQPGWw7GYVisfcsaM0bLmpx4XyJ7sMWLk +VG1gpdRhT424Tsr8c4RBetUbXGMqiZpcuROBcdGqNlF8uNJU7GDnTFoiIkcCVjjslts A5XoTzJGhObG8zgkm94QnG4De12Ltqxjv6gvXrwNOnEFzli8BP9JyrKqvEDST9p84ndz emxiaBGcQs8TNZO8J3tPDFQNEEODLNn+UFX9+aJpwqDUACotKo+3UHMoRcEOm6W579Lf vU+SeXr8Ji8M7Minjgt9ulhbugDZBQSJlNcsRBSfCMfzl8srYGSDr9yjOtihhMe8D5VA ySfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=QQ79ZCKYvGOvnQSyLErq8PGgwi3KQrUbDd4skZCRZBM=; b=JN1bbjaU5/RfSmd49ViiOueVp/679JubLDFm8I+bnX9uDk8mI2IU3dINRfE5h2Mb8Q /IwmzmAdB9lC1qmyESwu3JN6q7aalQZmW8qZk5je9ZMaN7ZoxFG8VIALderplot/VZ+y fNqoBYHi0Lbw99zpf5/TJ4c8D5ulqKsY2pN+5yZCrJoltFfoWyXGqAtJaLB1oYdFOEHw kzM0JvlJVFOXX7WXU+IM7rWKVvkoL8PGyOTbKQqPSVVUJa2NpUlBbBCQQQZWj/8mHiYr v6JBamFfCTORBf/hZX0K1+VSmGSao5VrTgz2Y03hAvh2QZwklHgGvz+d7fgklUN3Ylj7 nA8Q== X-Gm-Message-State: AOPr4FX3ZDRVr3zblzB5LTkViVxU9TKMf7aakoc+bccD98AYxdwlFRkYtPPJwayY5VsPiw== X-Received: by 10.55.31.65 with SMTP id f62mr8343999qkf.36.1463583268189; Wed, 18 May 2016 07:54:28 -0700 (PDT) Received: from [10.0.1.4] (c-24-218-52-148.hsd1.ma.comcast.net. [24.218.52.148]) by smtp.gmail.com with ESMTPSA id o130sm4300886qho.17.2016.05.18.07.54.27 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 May 2016 07:54:27 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_4DC4D282-6EC3-487B-8B4A-18DA4FC9F506" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Marie-Jose Montpetit In-Reply-To: <573C564E.1090201@bobbriscoe.net> Date: Wed, 18 May 2016 10:54:25 -0400 Message-Id: <23AFF031-4F76-410E-BF2A-6C045C284B57@mjmontpetit.com> References: <573C564E.1090201@bobbriscoe.net> To: Bob Briscoe X-Mailer: Apple Mail (2.3112) Archived-At: Cc: TCP Prague List Subject: Re: [tcpPrague] Volunteers pls: L4S non-WG-forming BoF proposal cut-off approaching X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 14:54:31 -0000 --Apple-Mail=_4DC4D282-6EC3-487B-8B4A-18DA4FC9F506 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Bob! While I cannot be sure I will make it to Berlin this work is very = pertinent to my current consuting/research; I could help with 1. = reviewing 2. maybe suggestions and 5. Marie-Jos=C3=A9 >> On May 18, 2016, at 7:47 AM, Bob Briscoe < = ietf@bobbriscoe.net = > wrote: >>=20 >> Folks, >>=20 >> At the Low Latency, Low Loss Scalable throughput (L4S) Bar Bof in = Buenos Aires, there was support for a BoF about L4S, In the IETF-96 = (Berlin) time-frame. >> It was decided to initially use this ML, even tho the scope of L4S is = wider than TCP Prague. >> Consensus was to aim for a non-WG-forming BoF, to demonstrate = willingness to work on the pieces in existing IETF WGs, and to = co-ordinate approaches to each WG. >>=20 >> The cut-off is now 2.5 weeks away.=20 >> *2016-06-03 (Friday):* Cut-off date for BOF proposal requests to Area = Directors at UTC 23:59.=20 >>=20 >> To organise a successful BoF (referring to rfc5434 = ), we need volunteers for the = following tasks: >> 1/ Draft a statement of problem & scope >> 2/ List planned deliverables (incl. implementation, spec drafting), = milestones and target WG (also identify any critical interdependencies) >> 3/ Identify and draft any necessary changes to WG charters, to cover = the above deliverables >> 4/ Discuss with relevant WG chairs and ADs [see background below] >> 5/ Identify volunteers (pref before the BoF) planning to work on each = deliverable >>=20 >> Some people have already volunteered in general to help with = arranging the BoF, but we now need to get specific. >>=20 >> Let's get volunteers for the above priority tasks first, but for = completeness I'll also list the formalities we have to do: >> a/ Decide on name of BoF (and mailing list) >> b/ BoF facilitators - chairs, scribes, etc >> c/ Draft the BoF agenda, incl. time constraints >> d/ Decide on the BoF questions >> e/ Estimate attendance, list conflicts, decide duration >> f/ Submit a formal request for the BoF via=20 >> http://www.ietf.org/instructions/MTG-SLOTS.html = and >> http://www.ietf.org/ietf/1bof-procedures.txt = >>=20 >> I'll start off co-ordinating and chasing all the above, but contact = me if you would like to take on the co-ordinating task. >>=20 >> Background work so far >>=20 >> The idea of this BoF has been floated with WG chairs and ADs for some = time now (since Nov'15 in Yokohama), except AFAIK, we haven't talked = with the RMCAT chairs. >> Also we have already done considerable work on defining the problem = while writing various drafts and papers about L4S. >>=20 >> But, that was just a small group of co-authors (me, Koen, Inton, = Olga). There's still a lot to do to build wider consensus. >> We can go ahead with a BoF scheduling request even if disagreements = on scope/problem remain.=20 >> But before the BoF itself, we need to have any such disagreements = ironed out. >>=20 >> At the Buenos Aires Bar Bof, we put up a todo list of pieces that = will need to be worked on: >> See http://www.bobbriscoe.net/presents/1604ietf/1604-l4s-bar-bof.pdf = = particularly slides 9 & 10=20 >> and the target WGs for each were: >> * TSVWG (the L4S identifier) >> * AQM (the AQM - the name gives the clue ;) >> * TCPM (the DCTCP-like congestion control, covering SCTP) >> * RMCAT (L4S variants of real-time congestion controls, or at least = standardise existing controls using the identifier) >>=20 >> I believe, formally, each WG has to decide to charter additional work = on its own ML. >>=20 >> [Since then, Ingemar has pointed out on this list that we also need = to get AQM & ECN-marking in radio networks, and that will require = working with/through other SDOs and/or developer groups that deal with = the MAC layer .=20 >> V. important, but let's push that to a separate thread.] >>=20 >> Many of the pieces have their own rationale, independent of L4S. The = idea of the BoF is to draw the bigger picture that motivates the work.=20= >> That doesn't preclude incremental work on the pieces for those who = are not motivated by a big picture. >>=20 >> Cheers >>=20 >>=20 >>=20 >> Bob >> --=20 >> ________________________________________________________________ >> Bob Briscoe http://bobbriscoe.net/ = _______________________________________________ >> tcpPrague mailing list >> tcpPrague@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpprague = >=20 --Apple-Mail=_4DC4D282-6EC3-487B-8B4A-18DA4FC9F506 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Bob!

While I cannot be sure I will make it to Berlin this work is = very pertinent to my current consuting/research; I could help with 1. = reviewing 2. maybe suggestions and 5.

Marie-Jos=C3=A9
On May 18, 2016, at 7:47 AM, Bob Briscoe <ietf@bobbriscoe.net> = wrote:

Folks,

At the Low Latency, Low Loss Scalable throughput (L4S) Bar = Bof in Buenos Aires, there was support for a BoF about L4S, In the = IETF-96 (Berlin) time-frame.
It was decided to initially = use this ML, even tho the scope of L4S is wider than TCP Prague.
Consensus was to aim for a non-WG-forming BoF, to demonstrate = willingness to work on the pieces in existing IETF WGs, and to = co-ordinate approaches to each WG.

The = cut-off is now 2.5 weeks away. 
*2016-06-03 = (Friday):* Cut-off date for BOF proposal requests to Area Directors at = UTC 23:59. 

To organise a successful = BoF (referring to rfc5434), we = need volunteers for the following tasks:
1/ Draft a = statement of problem & scope
2/ List planned = deliverables (incl. implementation, spec drafting), milestones and = target WG (also identify any critical interdependencies)
3/ = Identify and draft any necessary changes to WG charters, to cover the = above deliverables
4/ Discuss with relevant WG chairs and = ADs [see background below]
5/ Identify volunteers (pref = before the BoF) planning to work on each deliverable

Some people have already volunteered in general to help with = arranging the BoF, but we now need to get specific.

Let's get volunteers for the above priority tasks first, but = for completeness I'll also list the formalities we have to do:
a/ Decide on name of BoF (and mailing list)
b/ = BoF facilitators - chairs, scribes, etc
c/ Draft the BoF = agenda, incl. time constraints
d/ Decide on the BoF = questions
e/ Estimate attendance, list conflicts, decide = duration
f/ Submit a formal request for the BoF = via 
     http://www.ietf.o= rg/instructions/MTG-SLOTS.html and
     http://www.ietf.org/= ietf/1bof-procedures.txt

I'll start off = co-ordinating and chasing all the above, but contact me if you would = like to take on the co-ordinating task.

Background work so far

The idea of this BoF has been floated with WG chairs and ADs = for some time now (since Nov'15 in Yokohama), except AFAIK, we haven't = talked with the RMCAT chairs.
Also we have already done = considerable work on defining the problem while writing various drafts = and papers about L4S.

But, that was just a = small group of co-authors (me, Koen, Inton, Olga). There's still a lot = to do to build wider consensus.
We can go ahead with a BoF = scheduling request even if disagreements on scope/problem = remain. 
But before the BoF itself, we need to have = any such disagreements ironed out.

At the = Buenos Aires Bar Bof, we put up a todo list of pieces that will need to = be worked on:
See = http://www.bobbriscoe.net/presents/1604ietf/1604-l4s-bar-bof.pdf = particularly slides 9 & 10 
and the target WGs = for each were:
* TSVWG (the L4S identifier)
* = AQM (the AQM - the name gives the clue ;)
* TCPM (the = DCTCP-like congestion control, covering SCTP)
* RMCAT (L4S = variants of real-time congestion controls, or at least standardise = existing controls using the identifier)

I = believe, formally, each WG has to decide to charter additional work on = its own ML.

[Since then, Ingemar has = pointed out on this list that we also need to get AQM & ECN-marking = in radio networks, and that will require working with/through other SDOs = and/or developer groups that deal with the MAC layer . 
V. important, but let's push that to a separate thread.]

Many of the pieces have their own rationale, = independent of L4S. The idea of the BoF is to draw the bigger picture = that motivates the work. 
That doesn't preclude = incremental work on the pieces for those who are not motivated by a big = picture.

Cheers



Bob
--=20
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
____= ___________________________________________
tcpPrague = mailing list
tcpPrague@ietf.org
https://www.ietf.= org/mailman/listinfo/tcpprague


= --Apple-Mail=_4DC4D282-6EC3-487B-8B4A-18DA4FC9F506-- From nobody Wed May 18 09:19:26 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9162A12D1AA for ; Wed, 18 May 2016 09:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 WimevlixAQ17 for ; Wed, 18 May 2016 09:19:20 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 EDB6F12D1B3 for ; Wed, 18 May 2016 09:19:19 -0700 (PDT) Received: from 173.7.199.146.dyn.plus.net ([146.199.7.173]:38214 helo=[192.168.0.10]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1b34Bp-0001qe-TI for tcpPrague@ietf.org; Wed, 18 May 2016 17:19:18 +0100 To: TCP Prague List From: Bob Briscoe Message-ID: <573C9605.8080308@bobbriscoe.net> Date: Wed, 18 May 2016 17:19:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------020602090905010902060306" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: [tcpPrague] Draft L4S deliverables list X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 16:19:23 -0000 This is a multi-part message in MIME format. --------------020602090905010902060306 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Folks, Here's the table of potential deliverables that I presented in Buenos Aires. I've started to add volunteer's names. Pls continue... Each should probably be divided into implementation and drafting the spec, but let's assume any volunteer will do both/either. * * *Description** * *Draft(s)** * *Volunteers** * *Target WG** * 1) L4S identifier draft-briscoe-tsvwg-ecn-l4s-id authors on draft tsvwg? 2) The DualQ AQM draft-briscoe-aqm-dualq-coupled authors on draft aqm? *3)** * *Scalable Transport** * 3-1) Fall back to Reno/Cubic on loss Linux / tcpm 3-2) TCP ECN Feedback draft-ietf-tcpm-accurate-ecn authors on draft tcpm 3-4) Scaling TCP's Congestion Window for Small Round Trip Times Bob Briscoe, Marcelo Bagnulo Braun tcpm? 3-5) Reduce TCP / SCTCP / TCP Prague RTT-dependence tcpm? 3-6) Smooth ECN feedback over flow's RTT, not RTT hard-coded for DC tcpm? 3-7) Fall back to Reno/Cubic if classic ECN bottleneck detected tcpm? 3-8) Faster-than-additive increase Marcelo tcpm? 3-9) Less drastic exit from slow-start Marcelo, Bob tcpm? 4) “TCP Prague” (for the Internet) tcpm? 5) DCTCP bis (for data centres - may be the same as TCP Prague) draft-ietf-tcpm-dctcp (bis) tcpm? 6) "SCTP Prague" tcpm/tsvwg? 7) “RMCAT Prague” rmcat? *Notes:** *A line can be drawn somewhere around 3-7) to indicate that everything above is an essential safety feature (preventing starvation etc), while everything below (up to 3-9) is a performance improvement. 4,5,6) are essentially wrap-ups of the relevant elements from 3-1) to 3-9) for each different transport 7) might require one draft for Nada, one for SCREAM, etc or it might be possible to describe one simple delta for all RMCAT approaches. Whether we need all the bitty pieces 3-1) to 3-9) or whether we should go straight for the wrap-up solutions, is up for discussion. Bob -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------020602090905010902060306 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Folks,

Here's the table of potential deliverables that I presented in Buenos Aires. I've started to add volunteer's names.
Pls continue...

Each should probably be divided into implementation and drafting the spec, but let's assume any volunteer will do both/either.


 Description
 Draft(s)
 Volunteers
 Target WG
1) L4S identifier draft-briscoe-tsvwg-ecn-l4s-id authors on draft
 tsvwg?
2)
 The DualQ AQM draft-briscoe-aqm-dualq-coupled authors on draft aqm?





3)
 Scalable Transport


3-1) Fall back to Reno/Cubic on loss

Linux / tcpm
3-2) TCP ECN Feedback draft-ietf-tcpm-accurate-ecn authors on draft tcpm
3-4)
 Scaling TCP's Congestion Window for Small Round Trip Times
Bob Briscoe, Marcelo Bagnulo Braun tcpm?
3-5)
 Reduce TCP / SCTCP / TCP Prague RTT-dependence

tcpm?
3-6)
 Smooth ECN feedback over flow's RTT, not RTT hard-coded for DC

tcpm?
3-7)
 Fall back to Reno/Cubic if classic ECN bottleneck detected

tcpm?
3-8)
 Faster-than-additive increase
Marcelo
 tcpm?
3-9)
 Less drastic exit from slow-start
Marcelo, Bob
 tcpm?





4)
 “TCP Prague” (for the Internet)

tcpm?
5)
 DCTCP bis (for data centres - may be the same as TCP Prague) draft-ietf-tcpm-dctcp (bis)
tcpm?
6)
 "SCTP Prague"

tcpm/tsvwg?
7)
 “RMCAT Prague”

rmcat?

Notes:
A line can be drawn somewhere around 3-7) to indicate that everything above is an essential safety feature (preventing starvation etc), while everything below (up to 3-9) is a performance improvement.

4,5,6) are essentially wrap-ups of the relevant elements from 3-1) to 3-9) for each different transport
7) might require one draft for Nada, one for SCREAM, etc or it might be possible to describe one simple delta for all RMCAT approaches.

Whether we need all the bitty pieces 3-1) to 3-9) or whether we should go straight for the wrap-up solutions, is up for discussion.


Bob
   
     
-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------020602090905010902060306-- From nobody Wed May 18 10:06:21 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB58C12D567 for ; Wed, 18 May 2016 10:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.026 X-Spam-Level: X-Spam-Status: No, score=-4.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426] 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 FHpJ_6IDhk1D for ; Wed, 18 May 2016 10:06:18 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id DD46C12D562 for ; Wed, 18 May 2016 10:06:17 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id EE6F2C9416; Wed, 18 May 2016 13:06:12 -0400 (EDT) Date: Wed, 18 May 2016 13:06:12 -0400 From: John Leslie To: Bob Briscoe Message-ID: <20160518170612.GA56178@verdi> References: <573C564E.1090201@bobbriscoe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <573C564E.1090201@bobbriscoe.net> User-Agent: Mutt/1.4.1i Archived-At: Cc: TCP Prague List Subject: Re: [tcpPrague] Volunteers pls: L4S non-WG-forming BoF proposal cut-off approaching X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 17:06:20 -0000 Bob Briscoe wrote: > > At the Low Latency, Low Loss Scalable throughput (L4S) Bar Bof in Buenos > Aires, there was support for a BoF about L4S, In the IETF-96 (Berlin) > time-frame. > It was decided to initially use this ML, even tho the scope of L4S is > wider than TCP Prague. > Consensus was to aim for a non-WG-forming BoF, to demonstrate > willingness to work on the pieces in existing IETF WGs, and to > co-ordinate approaches to each WG. I'm not sure we're all convinced this work _can_ be done by the existing WGs -- if it can, I'm all for that. > To organise a successful BoF (referring to rfc5434 > ), we need volunteers for the > following tasks: > #/ Draft a statement of problem & scope > #/ List planned deliverables (incl. implementation, spec drafting), > milestones and target WG (also identify any critical interdependencies) > #/ Identify and draft any necessary changes to WG charters, to cover the > above deliverables > #/ Discuss with relevant WG chairs and ADs [see background below] > #/ Identify volunteers (pref before the BoF) planning to work on each > deliverable I'll volunteer for almost anything except going to Berlin... -- John Leslie From nobody Wed May 18 10:34:09 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8893E12D605 for ; Wed, 18 May 2016 10:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 BYiWO-cVeWMf for ; Wed, 18 May 2016 10:34:06 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 4E4A112D604 for ; Wed, 18 May 2016 10:34:06 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id DC8C19AE1A20C; Wed, 18 May 2016 17:34:00 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u4IHY4vq002202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 May 2016 17:34:04 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u4IHY3Uv024275 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 May 2016 19:34:03 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.44]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Wed, 18 May 2016 19:34:03 +0200 From: "Scharf, Michael (Nokia - DE)" To: Bob Briscoe , TCP Prague List Thread-Topic: [tcpPrague] Draft L4S deliverables list Thread-Index: AQHRsSER9d5upeCsTUmvOIBARxek9p++9EQw Date: Wed, 18 May 2016 17:34:03 +0000 Message-ID: <655C07320163294895BBADA28372AF5D4885A3C9@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <573C9605.8080308@bobbriscoe.net> In-Reply-To: <573C9605.8080308@bobbriscoe.net> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: multipart/alternative; boundary="_000_655C07320163294895BBADA28372AF5D4885A3C9FR712WXCHMBA15z_" MIME-Version: 1.0 Archived-At: Subject: Re: [tcpPrague] Draft L4S deliverables list X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 17:34:08 -0000 --_000_655C07320163294895BBADA28372AF5D4885A3C9FR712WXCHMBA15z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXMgdGhlcmUgcnVubmluZyBjb2RlPw0KDQpUaHgNCg0KTWljaGFlbA0KDQoNCkZyb206IHRjcFBy YWd1ZSBbbWFpbHRvOnRjcHByYWd1ZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQm9i IEJyaXNjb2UNClNlbnQ6IFdlZG5lc2RheSwgTWF5IDE4LCAyMDE2IDY6MTkgUE0NClRvOiBUQ1Ag UHJhZ3VlIExpc3QNClN1YmplY3Q6IFt0Y3BQcmFndWVdIERyYWZ0IEw0UyBkZWxpdmVyYWJsZXMg bGlzdA0KDQpGb2xrcywNCg0KSGVyZSdzIHRoZSB0YWJsZSBvZiBwb3RlbnRpYWwgZGVsaXZlcmFi bGVzIHRoYXQgSSBwcmVzZW50ZWQgaW4gQnVlbm9zIEFpcmVzLiBJJ3ZlIHN0YXJ0ZWQgdG8gYWRk IHZvbHVudGVlcidzIG5hbWVzLg0KUGxzIGNvbnRpbnVlLi4uDQoNCkVhY2ggc2hvdWxkIHByb2Jh Ymx5IGJlIGRpdmlkZWQgaW50byBpbXBsZW1lbnRhdGlvbiBhbmQgZHJhZnRpbmcgdGhlIHNwZWMs IGJ1dCBsZXQncyBhc3N1bWUgYW55IHZvbHVudGVlciB3aWxsIGRvIGJvdGgvZWl0aGVyLg0KDQpE ZXNjcmlwdGlvbg0KDQpEcmFmdChzKQ0KDQpWb2x1bnRlZXJzDQoNClRhcmdldCBXRw0KDQoxKQ0K DQpMNFMgaWRlbnRpZmllcg0KDQpkcmFmdC1icmlzY29lLXRzdndnLWVjbi1sNHMtaWQNCg0KYXV0 aG9ycyBvbiBkcmFmdA0KDQp0c3Z3Zz8NCg0KMikNCg0KVGhlIER1YWxRIEFRTQ0KDQpkcmFmdC1i cmlzY29lLWFxbS1kdWFscS1jb3VwbGVkDQoNCmF1dGhvcnMgb24gZHJhZnQNCg0KYXFtPw0KDQoN CjMpDQoNClNjYWxhYmxlIFRyYW5zcG9ydA0KDQozLTEpDQoNCkZhbGwgYmFjayB0byBSZW5vL0N1 YmljIG9uIGxvc3MNCg0KTGludXggLyB0Y3BtDQoNCjMtMikNCg0KVENQIEVDTiBGZWVkYmFjaw0K DQpkcmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUtZWNuDQoNCmF1dGhvcnMgb24gZHJhZnQNCg0KdGNw bQ0KDQozLTQpDQoNClNjYWxpbmcgVENQJ3MgQ29uZ2VzdGlvbiBXaW5kb3cgZm9yIFNtYWxsIFJv dW5kIFRyaXAgVGltZXMNCg0KQm9iIEJyaXNjb2UsIE1hcmNlbG8gQmFnbnVsbyBCcmF1bg0KDQp0 Y3BtPw0KDQozLTUpDQoNClJlZHVjZSBUQ1AgLyBTQ1RDUCAvIFRDUCBQcmFndWUgUlRULWRlcGVu ZGVuY2UNCg0KdGNwbT8NCg0KMy02KQ0KDQpTbW9vdGggRUNOIGZlZWRiYWNrIG92ZXIgZmxvdydz IFJUVCwgbm90IFJUVCBoYXJkLWNvZGVkIGZvciBEQw0KDQp0Y3BtPw0KDQozLTcpDQoNCkZhbGwg YmFjayB0byBSZW5vL0N1YmljIGlmIGNsYXNzaWMgRUNOIGJvdHRsZW5lY2sgZGV0ZWN0ZWQNCg0K dGNwbT8NCg0KMy04KQ0KDQpGYXN0ZXItdGhhbi1hZGRpdGl2ZSBpbmNyZWFzZQ0KDQpNYXJjZWxv DQoNCnRjcG0/DQoNCjMtOSkNCg0KTGVzcyBkcmFzdGljIGV4aXQgZnJvbSBzbG93LXN0YXJ0DQoN Ck1hcmNlbG8sIEJvYg0KDQp0Y3BtPw0KDQoNCjQpDQoNCuKAnFRDUCBQcmFndWXigJ0gKGZvciB0 aGUgSW50ZXJuZXQpDQoNCnRjcG0/DQoNCjUpDQoNCkRDVENQIGJpcyAoZm9yIGRhdGEgY2VudHJl cyAtIG1heSBiZSB0aGUgc2FtZSBhcyBUQ1AgUHJhZ3VlKQ0KDQpkcmFmdC1pZXRmLXRjcG0tZGN0 Y3AgKGJpcykNCg0KdGNwbT8NCg0KNikNCg0KIlNDVFAgUHJhZ3VlIg0KDQp0Y3BtL3RzdndnPw0K DQo3KQ0KDQrigJxSTUNBVCBQcmFndWXigJ0NCg0Kcm1jYXQ/DQoNCg0KTm90ZXM6DQpBIGxpbmUg Y2FuIGJlIGRyYXduIHNvbWV3aGVyZSBhcm91bmQgMy03KSB0byBpbmRpY2F0ZSB0aGF0IGV2ZXJ5 dGhpbmcgYWJvdmUgaXMgYW4gZXNzZW50aWFsIHNhZmV0eSBmZWF0dXJlIChwcmV2ZW50aW5nIHN0 YXJ2YXRpb24gZXRjKSwgd2hpbGUgZXZlcnl0aGluZyBiZWxvdyAodXAgdG8gMy05KSBpcyBhIHBl cmZvcm1hbmNlIGltcHJvdmVtZW50Lg0KDQo0LDUsNikgYXJlIGVzc2VudGlhbGx5IHdyYXAtdXBz IG9mIHRoZSByZWxldmFudCBlbGVtZW50cyBmcm9tIDMtMSkgdG8gMy05KSBmb3IgZWFjaCBkaWZm ZXJlbnQgdHJhbnNwb3J0DQo3KSBtaWdodCByZXF1aXJlIG9uZSBkcmFmdCBmb3IgTmFkYSwgb25l IGZvciBTQ1JFQU0sIGV0YyBvciBpdCBtaWdodCBiZSBwb3NzaWJsZSB0byBkZXNjcmliZSBvbmUg c2ltcGxlIGRlbHRhIGZvciBhbGwgUk1DQVQgYXBwcm9hY2hlcy4NCg0KV2hldGhlciB3ZSBuZWVk IGFsbCB0aGUgYml0dHkgcGllY2VzIDMtMSkgdG8gMy05KSBvciB3aGV0aGVyIHdlIHNob3VsZCBn byBzdHJhaWdodCBmb3IgdGhlIHdyYXAtdXAgc29sdXRpb25zLCBpcyB1cCBmb3IgZGlzY3Vzc2lv bi4NCg0KDQpCb2INCg0KDQoNCg0KLS0NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpCb2IgQnJpc2NvZSAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBodHRwOi8vYm9iYnJpc2NvZS5uZXQvDQo= --_000_655C07320163294895BBADA28372AF5D4885A3C9FR712WXCHMBA15z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToi Q291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXIN Cgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQt ZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQg NzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SXMgdGhlcmUg cnVubmluZyBjb2RlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGh4PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NaWNoYWVsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAw Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOndpbmRvd3RleHQiPiB0Y3BQcmFndWUgW21haWx0bzp0Y3BwcmFndWUtYm91bmNl c0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Qm9iIEJyaXNjb2U8YnI+DQo8Yj5TZW50 OjwvYj4gV2VkbmVzZGF5LCBNYXkgMTgsIDIwMTYgNjoxOSBQTTxicj4NCjxiPlRvOjwvYj4gVENQ IFByYWd1ZSBMaXN0PGJyPg0KPGI+U3ViamVjdDo8L2I+IFt0Y3BQcmFndWVdIERyYWZ0IEw0UyBk ZWxpdmVyYWJsZXMgbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+Rm9sa3MsPGJyPg0KPGJyPg0KSGVy ZSdzIHRoZSB0YWJsZSBvZiBwb3RlbnRpYWwgZGVsaXZlcmFibGVzIHRoYXQgSSBwcmVzZW50ZWQg aW4gQnVlbm9zIEFpcmVzLiBJJ3ZlIHN0YXJ0ZWQgdG8gYWRkIHZvbHVudGVlcidzIG5hbWVzLg0K PGJyPg0KUGxzIGNvbnRpbnVlLi4uPGJyPg0KPGJyPg0KRWFjaCBzaG91bGQgcHJvYmFibHkgYmUg ZGl2aWRlZCBpbnRvIGltcGxlbWVudGF0aW9uIGFuZCBkcmFmdGluZyB0aGUgc3BlYywgYnV0IGxl dCdzIGFzc3VtZSBhbnkgdm9sdW50ZWVyIHdpbGwgZG8gYm90aC9laXRoZXIuPG86cD48L286cD48 L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5n PSIwIiB3aWR0aD0iMTAwJSIgc3R5bGU9IndpZHRoOjEwMC4wJSI+DQo8dGJvZHk+DQo8dHI+DQo8 dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0Ij48 L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAx LjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5EZXNjcmlwdGlvbjwvYj48bzpwPjwvbzpw PjwvcD4NCjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjEuNXB0IDEuNXB0 IDEuNXB0IDEuNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkRyYWZ0KHMpPC9iPjxvOnA+ PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQg MS41cHQgMS41cHQgMS41cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+Vm9sdW50ZWVyczwv Yj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5n OjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPlRhcmdl dCBXRzwvYj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHZhbGlnbj0i dG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4xKTxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5 bGU9InBhZGRpbmc6MS41cHQgMS41cHQgMS41cHQgMS41cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+TDRTIGlkZW50aWZpZXI8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3Ai IHN0eWxlPSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPmRyYWZ0LWJyaXNjb2UtdHN2d2ctZWNuLWw0cy1pZDxvOnA+PC9vOnA+PC9wPg0KPC90 ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQgMS41cHQgMS41cHQgMS41 cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YXV0aG9ycyBvbiBkcmFmdDxvOnA+PC9vOnA+PC9w Pg0KPC90ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQgMS41cHQgMS41 cHQgMS41cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dHN2d2c/PG86cD48L286cD48L3A+DQo8 L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQg MS41cHQgMS41cHQgMS41cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Mik8bzpwPjwvbzpwPjwv cD4NCjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEu NXB0IDEuNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBEdWFsUSBBUU08bzpwPjwvbzpw PjwvcD4NCjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjEuNXB0IDEuNXB0 IDEuNXB0IDEuNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmRyYWZ0LWJyaXNjb2UtYXFtLWR1 YWxxLWNvdXBsZWQ8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxl PSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PmF1dGhvcnMgb24gZHJhZnQ8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3Ai IHN0eWxlPSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPmFxbT88bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHZhbGln bj0idG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+PC90ZD4NCjx0 ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQgMS41cHQgMS41cHQgMS41cHQiPjwv dGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0IDEu NXB0Ij48L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAx LjVwdCAxLjVwdCI+PC90ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQg MS41cHQgMS41cHQgMS41cHQiPjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHZhbGlnbj0idG9wIiBz dHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj4zKTwvYj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0 eWxlPSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPlNjYWxhYmxlIFRyYW5zcG9ydDwvYj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQg dmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0Ij48L3Rk Pg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVw dCI+PC90ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQgMS41cHQgMS41 cHQgMS41cHQiPjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFk ZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4zLTEp PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzox LjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5GYWxsIGJhY2sg dG8gUmVuby9DdWJpYyBvbiBsb3NzPG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHZhbGlnbj0i dG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+PC90ZD4NCjx0ZCB2 YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQgMS41cHQgMS41cHQgMS41cHQiPjwvdGQ+ DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxpbnV4IC8gdGNwbTxvOnA+PC9vOnA+PC9wPg0KPC90 ZD4NCjwvdHI+DQo8dHI+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjEuNXB0IDEu NXB0IDEuNXB0IDEuNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjMtMik8bzpwPjwvbzpwPjwv cD4NCjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEu NXB0IDEuNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRDUCBFQ04gRmVlZGJhY2s8bzpwPjwv bzpwPjwvcD4NCjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjEuNXB0IDEu NXB0IDEuNXB0IDEuNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmRyYWZ0LWlldGYtdGNwbS1h Y2N1cmF0ZS1lY248bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxl PSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PmF1dGhvcnMgb24gZHJhZnQ8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3Ai IHN0eWxlPSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPnRjcG08bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHZhbGln bj0idG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4zLTQpPG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHZhbGlnbj0idG9w IiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5TY2FsaW5nIFRDUCdzIENvbmdlc3Rpb24gV2luZG93IGZvciBTbWFsbCBSb3VuZCBU cmlwIFRpbWVzPG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0i cGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+PC90ZD4NCjx0ZCB2YWxpZ249InRvcCIg c3R5bGU9InBhZGRpbmc6MS41cHQgMS41cHQgMS41cHQgMS41cHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Qm9iIEJyaXNjb2UsIE1hcmNlbG8gQmFnbnVsbyBCcmF1bjxvOnA+PC9vOnA+PC9wPg0K PC90ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQgMS41cHQgMS41cHQg MS41cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGNwbT88bzpwPjwvbzpwPjwvcD4NCjwvdGQ+ DQo8L3RyPg0KPHRyPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVw dCAxLjVwdCAxLjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4zLTUpPG86cD48L286cD48L3A+ DQo8L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVw dCAxLjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWR1Y2UgVENQIC8gU0NUQ1AgLyBUQ1Ag UHJhZ3VlIFJUVC1kZXBlbmRlbmNlPG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHZhbGlnbj0i dG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+PC90ZD4NCjx0ZCB2 YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQgMS41cHQgMS41cHQgMS41cHQiPjwvdGQ+ DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRjcG0/PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90 cj4NCjx0cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQgMS41cHQgMS41 cHQgMS41cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+My02KTxvOnA+PC9vOnA+PC9wPg0KPC90 ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQgMS41cHQgMS41cHQgMS41 cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U21vb3RoIEVDTiBmZWVkYmFjayBvdmVyIGZsb3cn cyBSVFQsIG5vdCBSVFQgaGFyZC1jb2RlZCBmb3IgREM8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8 dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0Ij48 L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAx LjVwdCI+PC90ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQgMS41cHQg MS41cHQgMS41cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGNwbT88bzpwPjwvbzpwPjwvcD4N CjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzoxLjVw dCAxLjVwdCAxLjVwdCAxLjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4zLTcpPG86cD48L286 cD48L3A+DQo8L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVw dCAxLjVwdCAxLjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5GYWxsIGJhY2sgdG8gUmVuby9D dWJpYyBpZiBjbGFzc2ljIEVDTiBib3R0bGVuZWNrIGRldGVjdGVkPG86cD48L286cD48L3A+DQo8 L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAx LjVwdCI+PC90ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQgMS41cHQg MS41cHQgMS41cHQiPjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjEuNXB0 IDEuNXB0IDEuNXB0IDEuNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRjcG0/PG86cD48L286 cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRp bmc6MS41cHQgMS41cHQgMS41cHQgMS41cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+My04KTxv OnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41 cHQgMS41cHQgMS41cHQgMS41cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RmFzdGVyLXRoYW4t YWRkaXRpdmUgaW5jcmVhc2U8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3Ai IHN0eWxlPSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0Ij48L3RkPg0KPHRkIHZhbGln bj0idG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5NYXJjZWxvPG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHZhbGlnbj0i dG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj50Y3BtPzxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQg dmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjMtOSk8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgdmFsaWdu PSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkxlc3MgZHJhc3RpYyBleGl0IGZyb20gc2xvdy1zdGFydDxvOnA+PC9vOnA+ PC9wPg0KPC90ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQgMS41cHQg MS41cHQgMS41cHQiPjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjEuNXB0 IDEuNXB0IDEuNXB0IDEuNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1hcmNlbG8sIEJvYjxv OnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41 cHQgMS41cHQgMS41cHQgMS41cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGNwbT88bzpwPjwv bzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFk ZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+PC90ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5 bGU9InBhZGRpbmc6MS41cHQgMS41cHQgMS41cHQgMS41cHQiPjwvdGQ+DQo8dGQgdmFsaWduPSJ0 b3AiIHN0eWxlPSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0Ij48L3RkPg0KPHRkIHZh bGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+PC90ZD4N Cjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQgMS41cHQgMS41cHQgMS41cHQi PjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzoxLjVw dCAxLjVwdCAxLjVwdCAxLjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj40KTxvOnA+PC9vOnA+ PC9wPg0KPC90ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQgMS41cHQg MS41cHQgMS41cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+4oCcVENQIFByYWd1ZeKAnSAoZm9y IHRoZSBJbnRlcm5ldCk8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0 eWxlPSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0Ij48L3RkPg0KPHRkIHZhbGlnbj0i dG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+PC90ZD4NCjx0ZCB2 YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQgMS41cHQgMS41cHQgMS41cHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+dGNwbT88bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRy Pg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj41KTxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB2 YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQgMS41cHQgMS41cHQgMS41cHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+RENUQ1AgYmlzIChmb3IgZGF0YSBjZW50cmVzIC0gbWF5IGJlIHRo ZSBzYW1lIGFzIFRDUCBQcmFndWUpPG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHZhbGlnbj0i dG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5kcmFmdC1pZXRmLXRjcG0tZGN0Y3AgKGJpcyk8bzpwPjwvbzpwPjwvcD4NCjwv dGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0IDEu NXB0Ij48L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAx LjVwdCAxLjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50Y3BtPzxvOnA+PC9vOnA+PC9wPg0K PC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjEuNXB0 IDEuNXB0IDEuNXB0IDEuNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjYpPG86cD48L286cD48 L3A+DQo8L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAx LjVwdCAxLjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mcXVvdDtTQ1RQIFByYWd1ZSZxdW90 OzxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6 MS41cHQgMS41cHQgMS41cHQgMS41cHQiPjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJw YWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0Ij48L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBz dHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj50Y3BtL3RzdndnPzxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQg dmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjcpPG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHZhbGlnbj0i dG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj7igJxSTUNBVCBQcmFndWXigJ08bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQg dmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0Ij48L3Rk Pg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVw dCI+PC90ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQgMS41cHQgMS41 cHQgMS41cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cm1jYXQ/PG86cD48L286cD48L3A+DQo8 L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJy Pg0KPGI+Tm90ZXM6PGJyPg0KPC9iPkEgbGluZSBjYW4gYmUgZHJhd24gc29tZXdoZXJlIGFyb3Vu ZCAzLTcpIHRvIGluZGljYXRlIHRoYXQgZXZlcnl0aGluZyBhYm92ZSBpcyBhbiBlc3NlbnRpYWwg c2FmZXR5IGZlYXR1cmUgKHByZXZlbnRpbmcgc3RhcnZhdGlvbiBldGMpLCB3aGlsZSBldmVyeXRo aW5nIGJlbG93ICh1cCB0byAzLTkpIGlzIGEgcGVyZm9ybWFuY2UgaW1wcm92ZW1lbnQuPGJyPg0K PGJyPg0KNCw1LDYpIGFyZSBlc3NlbnRpYWxseSB3cmFwLXVwcyBvZiB0aGUgcmVsZXZhbnQgZWxl bWVudHMgZnJvbSAzLTEpIHRvIDMtOSkgZm9yIGVhY2ggZGlmZmVyZW50IHRyYW5zcG9ydDxicj4N CjcpIG1pZ2h0IHJlcXVpcmUgb25lIGRyYWZ0IGZvciBOYWRhLCBvbmUgZm9yIFNDUkVBTSwgZXRj IG9yIGl0IG1pZ2h0IGJlIHBvc3NpYmxlIHRvIGRlc2NyaWJlIG9uZSBzaW1wbGUgZGVsdGEgZm9y IGFsbCBSTUNBVCBhcHByb2FjaGVzLjxicj4NCjxicj4NCldoZXRoZXIgd2UgbmVlZCBhbGwgdGhl IGJpdHR5IHBpZWNlcyAzLTEpIHRvIDMtOSkgb3Igd2hldGhlciB3ZSBzaG91bGQgZ28gc3RyYWln aHQgZm9yIHRoZSB3cmFwLXVwIHNvbHV0aW9ucywgaXMgdXAgZm9yIGRpc2N1c3Npb24uPGJyPg0K PGJyPg0KPGJyPg0KQm9iPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IDxicj4NCiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyA8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwcmU+LS0gPG86cD48 L286cD48L3ByZT4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkJvYiBCcmlz Y29lJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly9ib2JicmlzY29lLm5ldC8iPmh0dHA6Ly9ib2Ji cmlzY29lLm5ldC88L2E+PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_655C07320163294895BBADA28372AF5D4885A3C9FR712WXCHMBA15z_-- From nobody Wed May 18 12:22:07 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56EFE12D648 for ; Wed, 18 May 2016 12:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.83 X-Spam-Level: X-Spam-Status: No, score=-101.83 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it-uc3m-es.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wgQguM5ZMih for ; Wed, 18 May 2016 12:22:03 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 12E1712D13B for ; Wed, 18 May 2016 12:22:03 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id n129so199642718wmn.1 for ; Wed, 18 May 2016 12:22:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=Qot+bgPw1PnumcrHJgukEfRBiKTOGfo2d5uYIE8FhOw=; b=OeCT5N+es5D6eqbwUjVd/c+9IzCEroFprjiYM9Tap3gcWbTQiBIzE3JOWuyYbpITe6 hC0bNHo8zA8PE2hZ8P3lfutvKu+7dl79kQ9MwvMBEALTmajKnrC62S278qzcNeQZArZ2 1rAxMIx95nTdiReZ+p11yukLiG66ewOmCVuWcK1imksHpXMWu2l3UH5mC8P+9qrwMMAE OvWK0GXN06CBwxxakNydMcvfxytT+ro01N14GJyi6eFBdRJhh8x4i9jLo2+UwUZYd1ky rcW3C9g99Vfjg4/GvVPpgX5dN0RqVpWou6XuErbVX2V4ynilyjYXyqulTQSruqdX02De seVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Qot+bgPw1PnumcrHJgukEfRBiKTOGfo2d5uYIE8FhOw=; b=ZMkdiQJ+ug1KzU1PPhb6aRw8asNmVfiaXKWlK/WXWe/5oCEr/ltTNinh5Vo26gf+4U npA3tUJyArtMH95I+vybpbK5r1qwSSKfXy5Pgflf8V2OIK/jgIpji4daqtWVjy20jndv 8E/YuS2OP9agzLtuzamCqWPWHLHqGLl1il1kt/8bWVqZBRJScDJUEB3eHMdvnbTzGGgd CC/OGav3taA0ASVZds7HMTgSrQBgOVFqpAVQa263fjUcUhYXNldxesyPuXVNvVLmHV4v 9Ymk+Gi9sVfn6TvTF9xB7Xg7iZl0LVi0Gsh+rnzLHypnpxv3EMFsQCJv/beAGcf4esvB ci8Q== X-Gm-Message-State: AOPr4FVDBOvi/Z4UH4d1ybazuvGaEXkqKV52MPMwxlwD42sGbNHyIQhrX0eCX0iioQ7o9atr X-Received: by 10.194.173.161 with SMTP id bl1mr9188022wjc.11.1463599321312; Wed, 18 May 2016 12:22:01 -0700 (PDT) Received: from Macintosh-6.local (pa2-84-91-102-82.netvisao.pt. [84.91.102.82]) by smtp.gmail.com with ESMTPSA id y3sm10192501wji.40.2016.05.18.12.22.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 May 2016 12:22:00 -0700 (PDT) To: tcpprague@ietf.org References: <573C564E.1090201@bobbriscoe.net> From: marcelo bagnulo braun Message-ID: <573CC0EB.6060306@it.uc3m.es> Date: Wed, 18 May 2016 21:22:19 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <573C564E.1090201@bobbriscoe.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tcpPrague] Volunteers pls: L4S non-WG-forming BoF proposal cut-off approaching X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 19:22:05 -0000 Hi, I am happy to help with #1, #2 and support you with any any of the formalities Regards, marcelo El 18/05/16 a las 13:47, Bob Briscoe escribi: > Folks, > > At the Low Latency, Low Loss Scalable throughput (L4S) Bar Bof in > Buenos Aires, there was support for a BoF about L4S, In the IETF-96 > (Berlin) time-frame. > It was decided to initially use this ML, even tho the scope of L4S is > wider than TCP Prague. > Consensus was to aim for a non-WG-forming BoF, to demonstrate > willingness to work on the pieces in existing IETF WGs, and to > co-ordinate approaches to each WG. > > The cut-off is now 2.5 weeks away. > *2016-06-03 (Friday):* Cut-off date for BOF proposal requests to Area > Directors at UTC 23:59. > > To organise a successful BoF (referring to rfc5434 > ), we need volunteers for the > following tasks: > #/ Draft a statement of problem & scope > #/ List planned deliverables (incl. implementation, spec drafting), > milestones and target WG (also identify any critical interdependencies) > #/ Identify and draft any necessary changes to WG charters, to cover > the above deliverables > #/ Discuss with relevant WG chairs and ADs [see background below] > #/ Identify volunteers (pref before the BoF) planning to work on each > deliverable > > Some people have already volunteered in general to help with arranging > the BoF, but we now need to get specific. > > Let's get volunteers for the above priority tasks first, but for > completeness I'll also list the formalities we have to do: > #/ Decide on name of BoF (and mailing list) > #/ BoF facilitators - chairs, scribes, etc > #/ Draft the BoF agenda, incl. time constraints > #/ Decide on the BoF questions > #/ Estimate attendance, list conflicts, decide duration > #/ Submit a formal request for the BoF via > http://www.ietf.org/instructions/MTG-SLOTS.html and > http://www.ietf.org/ietf/1bof-procedures.txt > > I'll start off co-ordinating and chasing all the above, but contact me > if you would like to take on the co-ordinating task. > > *Background work so far** > * > The idea of this BoF has been floated with WG chairs and ADs for some > time now (since Nov'15 in Yokohama), except AFAIK, we haven't talked > with the RMCAT chairs. > Also we have already done considerable work on defining the problem > while writing various drafts and papers about L4S. > > But, that was just a small group of co-authors (me, Koen, Inton, > Olga). There's still a lot to do to build wider consensus. > We can go ahead with a BoF scheduling request even if disagreements on > scope/problem remain. > But before the BoF itself, we need to have any such disagreements > ironed out. > > At the Buenos Aires Bar Bof, we put up a todo list of pieces that will > need to be worked on: > See http://www.bobbriscoe.net/presents/1604ietf/1604-l4s-bar-bof.pdf > particularly slides 9 & 10 > and the target WGs for each were: > * TSVWG (the L4S identifier) > * AQM (the AQM - the name gives the clue ;) > * TCPM (the DCTCP-like congestion control, covering SCTP) > * RMCAT (L4S variants of real-time congestion controls, or at least > standardise existing controls using the identifier) > > I believe, formally, each WG has to decide to charter additional work > on its own ML. > > [Since then, Ingemar has pointed out on this list that we also need to > get AQM & ECN-marking in radio networks, and that will require working > with/through other SDOs and/or developer groups that deal with the MAC > layer . > V. important, but let's push that to a separate thread.] > > Many of the pieces have their own rationale, independent of L4S. The > idea of the BoF is to draw the bigger picture that motivates the work. > That doesn't preclude incremental work on the pieces for those who are > not motivated by a big picture. > > Cheers > > > > Bob > -- > ________________________________________________________________ > Bob Briscoehttp://bobbriscoe.net/ > > > _______________________________________________ > tcpPrague mailing list > tcpPrague@ietf.org > https://www.ietf.org/mailman/listinfo/tcpprague From nobody Thu May 19 01:59:48 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 087A112D16B for ; Thu, 19 May 2016 01:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 UkH_F0OTjgJk for ; Thu, 19 May 2016 01:59:43 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 0CEB412D138 for ; Thu, 19 May 2016 01:59:36 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 2596FD5EAB61D; Thu, 19 May 2016 08:59:32 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u4J8xX3Y000436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 May 2016 08:59:33 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u4J8wK86019135 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 May 2016 10:59:32 +0200 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.203]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Thu, 19 May 2016 10:59:04 +0200 From: "De Schepper, Koen (Nokia - BE)" To: Bob Briscoe , TCP Prague List Thread-Topic: [tcpPrague] Draft L4S deliverables list Thread-Index: AQHRsSERcasadcLDHUypp3oMSIJcD5+/75tg Date: Thu, 19 May 2016 08:59:03 +0000 Message-ID: References: <573C9605.8080308@bobbriscoe.net> In-Reply-To: <573C9605.8080308@bobbriscoe.net> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: multipart/alternative; boundary="_000_BF6B00CC65FD2D45A326E74492B2C19FB7682B62FR711WXCHMBA05z_" MIME-Version: 1.0 Archived-At: Subject: Re: [tcpPrague] Draft L4S deliverables list X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 08:59:46 -0000 --_000_BF6B00CC65FD2D45A326E74492B2C19FB7682B62FR711WXCHMBA05z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQm9iLA0KDQpJIHdhbnQgdG8gaGVscCBvbiAxLCAyIGFuZCBtb3N0IG9mIHRoZSB0b3BpY3Mg aW4gMyBtYWlubHkgaW4gdGhlIHNjb3BlIG9mIDQsIHdpdGggaW1wbGVtZW50YXRpb25zIGZvciBM aW51eC4NCg0KS29lbi4NCg0KDQoNCg0KRnJvbTogdGNwUHJhZ3VlIFttYWlsdG86dGNwcHJhZ3Vl LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCb2IgQnJpc2NvZQ0KU2VudDogd29lbnNk YWcgMTggbWVpIDIwMTYgMTg6MTkNClRvOiBUQ1AgUHJhZ3VlIExpc3QNClN1YmplY3Q6IFt0Y3BQ cmFndWVdIERyYWZ0IEw0UyBkZWxpdmVyYWJsZXMgbGlzdA0KDQpGb2xrcywNCg0KSGVyZSdzIHRo ZSB0YWJsZSBvZiBwb3RlbnRpYWwgZGVsaXZlcmFibGVzIHRoYXQgSSBwcmVzZW50ZWQgaW4gQnVl bm9zIEFpcmVzLiBJJ3ZlIHN0YXJ0ZWQgdG8gYWRkIHZvbHVudGVlcidzIG5hbWVzLg0KUGxzIGNv bnRpbnVlLi4uDQoNCkVhY2ggc2hvdWxkIHByb2JhYmx5IGJlIGRpdmlkZWQgaW50byBpbXBsZW1l bnRhdGlvbiBhbmQgZHJhZnRpbmcgdGhlIHNwZWMsIGJ1dCBsZXQncyBhc3N1bWUgYW55IHZvbHVu dGVlciB3aWxsIGRvIGJvdGgvZWl0aGVyLg0KDQpEZXNjcmlwdGlvbg0KDQpEcmFmdChzKQ0KDQpW b2x1bnRlZXJzDQoNClRhcmdldCBXRw0KDQoxKQ0KDQpMNFMgaWRlbnRpZmllcg0KDQpkcmFmdC1i cmlzY29lLXRzdndnLWVjbi1sNHMtaWQNCg0KYXV0aG9ycyBvbiBkcmFmdA0KDQp0c3Z3Zz8NCg0K MikNCg0KVGhlIER1YWxRIEFRTQ0KDQpkcmFmdC1icmlzY29lLWFxbS1kdWFscS1jb3VwbGVkDQoN CmF1dGhvcnMgb24gZHJhZnQNCg0KYXFtPw0KDQoNCjMpDQoNClNjYWxhYmxlIFRyYW5zcG9ydA0K DQozLTEpDQoNCkZhbGwgYmFjayB0byBSZW5vL0N1YmljIG9uIGxvc3MNCg0KTGludXggLyB0Y3Bt DQoNCjMtMikNCg0KVENQIEVDTiBGZWVkYmFjaw0KDQpkcmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUt ZWNuDQoNCmF1dGhvcnMgb24gZHJhZnQNCg0KdGNwbQ0KDQozLTQpDQoNClNjYWxpbmcgVENQJ3Mg Q29uZ2VzdGlvbiBXaW5kb3cgZm9yIFNtYWxsIFJvdW5kIFRyaXAgVGltZXMNCg0KQm9iIEJyaXNj b2UsIE1hcmNlbG8gQmFnbnVsbyBCcmF1bg0KDQp0Y3BtPw0KDQozLTUpDQoNClJlZHVjZSBUQ1Ag LyBTQ1RDUCAvIFRDUCBQcmFndWUgUlRULWRlcGVuZGVuY2UNCg0KdGNwbT8NCg0KMy02KQ0KDQpT bW9vdGggRUNOIGZlZWRiYWNrIG92ZXIgZmxvdydzIFJUVCwgbm90IFJUVCBoYXJkLWNvZGVkIGZv ciBEQw0KDQp0Y3BtPw0KDQozLTcpDQoNCkZhbGwgYmFjayB0byBSZW5vL0N1YmljIGlmIGNsYXNz aWMgRUNOIGJvdHRsZW5lY2sgZGV0ZWN0ZWQNCg0KdGNwbT8NCg0KMy04KQ0KDQpGYXN0ZXItdGhh bi1hZGRpdGl2ZSBpbmNyZWFzZQ0KDQpNYXJjZWxvDQoNCnRjcG0/DQoNCjMtOSkNCg0KTGVzcyBk cmFzdGljIGV4aXQgZnJvbSBzbG93LXN0YXJ0DQoNCk1hcmNlbG8sIEJvYg0KDQp0Y3BtPw0KDQoN CjQpDQoNCuKAnFRDUCBQcmFndWXigJ0gKGZvciB0aGUgSW50ZXJuZXQpDQoNCnRjcG0/DQoNCjUp DQoNCkRDVENQIGJpcyAoZm9yIGRhdGEgY2VudHJlcyAtIG1heSBiZSB0aGUgc2FtZSBhcyBUQ1Ag UHJhZ3VlKQ0KDQpkcmFmdC1pZXRmLXRjcG0tZGN0Y3AgKGJpcykNCg0KdGNwbT8NCg0KNikNCg0K IlNDVFAgUHJhZ3VlIg0KDQp0Y3BtL3RzdndnPw0KDQo3KQ0KDQrigJxSTUNBVCBQcmFndWXigJ0N Cg0Kcm1jYXQ/DQoNCg0KTm90ZXM6DQpBIGxpbmUgY2FuIGJlIGRyYXduIHNvbWV3aGVyZSBhcm91 bmQgMy03KSB0byBpbmRpY2F0ZSB0aGF0IGV2ZXJ5dGhpbmcgYWJvdmUgaXMgYW4gZXNzZW50aWFs IHNhZmV0eSBmZWF0dXJlIChwcmV2ZW50aW5nIHN0YXJ2YXRpb24gZXRjKSwgd2hpbGUgZXZlcnl0 aGluZyBiZWxvdyAodXAgdG8gMy05KSBpcyBhIHBlcmZvcm1hbmNlIGltcHJvdmVtZW50Lg0KDQo0 LDUsNikgYXJlIGVzc2VudGlhbGx5IHdyYXAtdXBzIG9mIHRoZSByZWxldmFudCBlbGVtZW50cyBm cm9tIDMtMSkgdG8gMy05KSBmb3IgZWFjaCBkaWZmZXJlbnQgdHJhbnNwb3J0DQo3KSBtaWdodCBy ZXF1aXJlIG9uZSBkcmFmdCBmb3IgTmFkYSwgb25lIGZvciBTQ1JFQU0sIGV0YyBvciBpdCBtaWdo dCBiZSBwb3NzaWJsZSB0byBkZXNjcmliZSBvbmUgc2ltcGxlIGRlbHRhIGZvciBhbGwgUk1DQVQg YXBwcm9hY2hlcy4NCg0KV2hldGhlciB3ZSBuZWVkIGFsbCB0aGUgYml0dHkgcGllY2VzIDMtMSkg dG8gMy05KSBvciB3aGV0aGVyIHdlIHNob3VsZCBnbyBzdHJhaWdodCBmb3IgdGhlIHdyYXAtdXAg c29sdXRpb25zLCBpcyB1cCBmb3IgZGlzY3Vzc2lvbi4NCg0KDQpCb2INCg0KDQoNCg0KLS0NCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KDQpCb2IgQnJpc2NvZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBodHRw Oi8vYm9iYnJpc2NvZS5uZXQvDQo= --_000_BF6B00CC65FD2D45A326E74492B2C19FB7682B62FR711WXCHMBA05z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToi Q291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXIN Cgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQt ZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQg NzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9Ik5MLUJFIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkhpIEJvYiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB3YW50IHRv IGhlbHAgb24gMSwgMiBhbmQgbW9zdCBvZiB0aGUgdG9waWNzIGluIDMgbWFpbmx5IGluIHRoZSBz Y29wZSBvZiA0LCB3aXRoIGltcGxlbWVudGF0aW9ucyBmb3IgTGludXguPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPktvZW4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndp bmRvd3RleHQiPiB0Y3BQcmFndWUgW21haWx0bzp0Y3BwcmFndWUtYm91bmNlc0BpZXRmLm9yZ10N CjxiPk9uIEJlaGFsZiBPZiA8L2I+Qm9iIEJyaXNjb2U8YnI+DQo8Yj5TZW50OjwvYj4gd29lbnNk YWcgMTggbWVpIDIwMTYgMTg6MTk8YnI+DQo8Yj5Ubzo8L2I+IFRDUCBQcmFndWUgTGlzdDxicj4N CjxiPlN1YmplY3Q6PC9iPiBbdGNwUHJhZ3VlXSBEcmFmdCBMNFMgZGVsaXZlcmFibGVzIGxpc3Q8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPkZvbGtzLDxicj4NCjxicj4NCkhlcmUncyB0aGUgdGFibGUgb2Yg cG90ZW50aWFsIGRlbGl2ZXJhYmxlcyB0aGF0IEkgcHJlc2VudGVkIGluIEJ1ZW5vcyBBaXJlcy4g SSd2ZSBzdGFydGVkIHRvIGFkZCB2b2x1bnRlZXIncyBuYW1lcy4NCjxicj4NClBscyBjb250aW51 ZS4uLjxicj4NCjxicj4NCkVhY2ggc2hvdWxkIHByb2JhYmx5IGJlIGRpdmlkZWQgaW50byBpbXBs ZW1lbnRhdGlvbiBhbmQgZHJhZnRpbmcgdGhlIHNwZWMsIGJ1dCBsZXQncyBhc3N1bWUgYW55IHZv bHVudGVlciB3aWxsIGRvIGJvdGgvZWl0aGVyLjxvOnA+PC9vOnA+PC9wPg0KPHRhYmxlIGNsYXNz PSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjEwMCUi IHN0eWxlPSJ3aWR0aDoxMDAuMCUiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHZhbGlnbj0idG9wIiBz dHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+PC90ZD4NCjx0ZCB2YWxpZ249 InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQgMS41cHQgMS41cHQgMS41cHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+RGVzY3JpcHRpb248L2I+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRk IHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5EcmFmdChzKTwvYj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+ DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPlZvbHVudGVlcnM8L2I+PG86cD48L286cD48L3A+ DQo8L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVw dCAxLjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5UYXJnZXQgV0c8L2I+PG86cD48L286 cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRp bmc6MS41cHQgMS41cHQgMS41cHQgMS41cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MSk8bzpw PjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjEuNXB0 IDEuNXB0IDEuNXB0IDEuNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkw0UyBpZGVudGlmaWVy PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzox LjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5kcmFmdC1icmlz Y29lLXRzdndnLWVjbi1sNHMtaWQ8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgdmFsaWduPSJ0 b3AiIHN0eWxlPSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPmF1dGhvcnMgb24gZHJhZnQ8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgdmFs aWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPnRzdndnPzxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+ DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIpPG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHZh bGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5UaGUgRHVhbFEgQVFNPG86cD48L286cD48L3A+DQo8L3RkPg0KPHRk IHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5kcmFmdC1icmlzY29lLWFxbS1kdWFscS1jb3VwbGVkPG86cD48 L286cD48L3A+DQo8L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAx LjVwdCAxLjVwdCAxLjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hdXRob3JzIG9uIGRyYWZ0 PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzox LjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hcW0/PG86cD48 L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBh ZGRpbmc6MS41cHQgMS41cHQgMS41cHQgMS41cHQiPjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0 eWxlPSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0Ij48L3RkPg0KPHRkIHZhbGlnbj0i dG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+PC90ZD4NCjx0ZCB2 YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQgMS41cHQgMS41cHQgMS41cHQiPjwvdGQ+ DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0 Ij48L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41 cHQgMS41cHQgMS41cHQgMS41cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+Myk8L2I+PG86 cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzoxLjVw dCAxLjVwdCAxLjVwdCAxLjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5TY2FsYWJsZSBU cmFuc3BvcnQ8L2I+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBzdHls ZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+PC90ZD4NCjx0ZCB2YWxpZ249InRv cCIgc3R5bGU9InBhZGRpbmc6MS41cHQgMS41cHQgMS41cHQgMS41cHQiPjwvdGQ+DQo8dGQgdmFs aWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0Ij48L3RkPg0K PC90cj4NCjx0cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQgMS41cHQg MS41cHQgMS41cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+My0xKTxvOnA+PC9vOnA+PC9wPg0K PC90ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQgMS41cHQgMS41cHQg MS41cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RmFsbCBiYWNrIHRvIFJlbm8vQ3ViaWMgb24g bG9zczxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRp bmc6MS41cHQgMS41cHQgMS41cHQgMS41cHQiPjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxl PSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0Ij48L3RkPg0KPHRkIHZhbGlnbj0idG9w IiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5MaW51eCAvIHRjcG08bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0K PHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4zLTIpPG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHZh bGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5UQ1AgRUNOIEZlZWRiYWNrPG86cD48L286cD48L3A+DQo8L3RkPg0K PHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5kcmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUtZWNuPG86cD48 L286cD48L3A+DQo8L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAx LjVwdCAxLjVwdCAxLjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hdXRob3JzIG9uIGRyYWZ0 PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzox LjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50Y3BtPG86cD48 L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBh ZGRpbmc6MS41cHQgMS41cHQgMS41cHQgMS41cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+My00 KTxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6 MS41cHQgMS41cHQgMS41cHQgMS41cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2NhbGluZyBU Q1AncyBDb25nZXN0aW9uIFdpbmRvdyBmb3IgU21hbGwgUm91bmQgVHJpcCBUaW1lczxvOnA+PC9v OnA+PC9wPg0KPC90ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQgMS41 cHQgMS41cHQgMS41cHQiPjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjEu NXB0IDEuNXB0IDEuNXB0IDEuNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJvYiBCcmlzY29l LCBNYXJjZWxvIEJhZ251bG8gQnJhdW48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgdmFsaWdu PSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPnRjcG0/PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0 ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQgMS41cHQgMS41cHQgMS41cHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+My01KTxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB2YWxp Z249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQgMS41cHQgMS41cHQgMS41cHQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+UmVkdWNlIFRDUCAvIFNDVENQIC8gVENQIFByYWd1ZSBSVFQtZGVwZW5k ZW5jZTxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRp bmc6MS41cHQgMS41cHQgMS41cHQgMS41cHQiPjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxl PSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0Ij48L3RkPg0KPHRkIHZhbGlnbj0idG9w IiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj50Y3BtPzxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgdmFs aWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjMtNik8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgdmFsaWduPSJ0 b3AiIHN0eWxlPSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlNtb290aCBFQ04gZmVlZGJhY2sgb3ZlciBmbG93J3MgUlRULCBub3QgUlRUIGhh cmQtY29kZWQgZm9yIERDPG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBz dHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+PC90ZD4NCjx0ZCB2YWxpZ249 InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQgMS41cHQgMS41cHQgMS41cHQiPjwvdGQ+DQo8dGQg dmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPnRjcG0/PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0 cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQgMS41cHQgMS41cHQgMS41 cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+My03KTxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0 ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQgMS41cHQgMS41cHQgMS41cHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+RmFsbCBiYWNrIHRvIFJlbm8vQ3ViaWMgaWYgY2xhc3NpYyBF Q04gYm90dGxlbmVjayBkZXRlY3RlZDxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB2YWxpZ249 InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQgMS41cHQgMS41cHQgMS41cHQiPjwvdGQ+DQo8dGQg dmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0Ij48L3Rk Pg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50Y3BtPzxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwv dHI+DQo8dHI+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEu NXB0IDEuNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjMtOCk8bzpwPjwvbzpwPjwvcD4NCjwv dGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0IDEu NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZhc3Rlci10aGFuLWFkZGl0aXZlIGluY3JlYXNl PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzox LjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+PC90ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBh ZGRpbmc6MS41cHQgMS41cHQgMS41cHQgMS41cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWFy Y2VsbzxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRp bmc6MS41cHQgMS41cHQgMS41cHQgMS41cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGNwbT88 bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHZhbGlnbj0idG9wIiBzdHls ZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4zLTkpPG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFk ZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5MZXNz IGRyYXN0aWMgZXhpdCBmcm9tIHNsb3ctc3RhcnQ8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQg dmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0Ij48L3Rk Pg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NYXJjZWxvLCBCb2I8bzpwPjwvbzpwPjwvcD4NCjwv dGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0IDEu NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRjcG0/PG86cD48L286cD48L3A+DQo8L3RkPg0K PC90cj4NCjx0cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQgMS41cHQg MS41cHQgMS41cHQiPjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjEuNXB0 IDEuNXB0IDEuNXB0IDEuNXB0Ij48L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGlu ZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+PC90ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9 InBhZGRpbmc6MS41cHQgMS41cHQgMS41cHQgMS41cHQiPjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3Ai IHN0eWxlPSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0Ij48L3RkPg0KPC90cj4NCjx0 cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQgMS41cHQgMS41cHQgMS41 cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+NCk8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQg dmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPuKAnFRDUCBQcmFndWXigJ0gKGZvciB0aGUgSW50ZXJuZXQpPG86 cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzoxLjVw dCAxLjVwdCAxLjVwdCAxLjVwdCI+PC90ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRp bmc6MS41cHQgMS41cHQgMS41cHQgMS41cHQiPjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxl PSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PnRjcG0/PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCB2YWxpZ249InRv cCIgc3R5bGU9InBhZGRpbmc6MS41cHQgMS41cHQgMS41cHQgMS41cHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+NSk8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxl PSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkRDVENQIGJpcyAoZm9yIGRhdGEgY2VudHJlcyAtIG1heSBiZSB0aGUgc2FtZSBhcyBUQ1AgUHJh Z3VlKTxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRp bmc6MS41cHQgMS41cHQgMS41cHQgMS41cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ZHJhZnQt aWV0Zi10Y3BtLWRjdGNwIChiaXMpPG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHZhbGlnbj0i dG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+PC90ZD4NCjx0ZCB2 YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQgMS41cHQgMS41cHQgMS41cHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+dGNwbT88bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRy Pg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj42KTxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB2 YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQgMS41cHQgMS41cHQgMS41cHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+JnF1b3Q7U0NUUCBQcmFndWUmcXVvdDs8bzpwPjwvbzpwPjwvcD4N CjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0 IDEuNXB0Ij48L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVw dCAxLjVwdCAxLjVwdCI+PC90ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41 cHQgMS41cHQgMS41cHQgMS41cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGNwbS90c3Z3Zz88 bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHZhbGlnbj0idG9wIiBzdHls ZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij43KTxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRp bmc6MS41cHQgMS41cHQgMS41cHQgMS41cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+4oCcUk1D QVQgUHJhZ3Vl4oCdPG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBzdHls ZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+PC90ZD4NCjx0ZCB2YWxpZ249InRv cCIgc3R5bGU9InBhZGRpbmc6MS41cHQgMS41cHQgMS41cHQgMS41cHQiPjwvdGQ+DQo8dGQgdmFs aWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPnJtY2F0PzxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Ri b2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxiPk5vdGVzOjxicj4N CjwvYj5BIGxpbmUgY2FuIGJlIGRyYXduIHNvbWV3aGVyZSBhcm91bmQgMy03KSB0byBpbmRpY2F0 ZSB0aGF0IGV2ZXJ5dGhpbmcgYWJvdmUgaXMgYW4gZXNzZW50aWFsIHNhZmV0eSBmZWF0dXJlIChw cmV2ZW50aW5nIHN0YXJ2YXRpb24gZXRjKSwgd2hpbGUgZXZlcnl0aGluZyBiZWxvdyAodXAgdG8g My05KSBpcyBhIHBlcmZvcm1hbmNlIGltcHJvdmVtZW50Ljxicj4NCjxicj4NCjQsNSw2KSBhcmUg ZXNzZW50aWFsbHkgd3JhcC11cHMgb2YgdGhlIHJlbGV2YW50IGVsZW1lbnRzIGZyb20gMy0xKSB0 byAzLTkpIGZvciBlYWNoIGRpZmZlcmVudCB0cmFuc3BvcnQ8YnI+DQo3KSBtaWdodCByZXF1aXJl IG9uZSBkcmFmdCBmb3IgTmFkYSwgb25lIGZvciBTQ1JFQU0sIGV0YyBvciBpdCBtaWdodCBiZSBw b3NzaWJsZSB0byBkZXNjcmliZSBvbmUgc2ltcGxlIGRlbHRhIGZvciBhbGwgUk1DQVQgYXBwcm9h Y2hlcy48YnI+DQo8YnI+DQpXaGV0aGVyIHdlIG5lZWQgYWxsIHRoZSBiaXR0eSBwaWVjZXMgMy0x KSB0byAzLTkpIG9yIHdoZXRoZXIgd2Ugc2hvdWxkIGdvIHN0cmFpZ2h0IGZvciB0aGUgd3JhcC11 cCBzb2x1dGlvbnMsIGlzIHVwIGZvciBkaXNjdXNzaW9uLjxicj4NCjxicj4NCjxicj4NCkJvYjxi cj4NCiZuYnNwOyZuYnNwOyZuYnNwOyA8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGJy Pg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cHJlPi0tIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Cb2IgQnJpc2NvZSZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBo cmVmPSJodHRwOi8vYm9iYnJpc2NvZS5uZXQvIj5odHRwOi8vYm9iYnJpc2NvZS5uZXQvPC9hPjxv OnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BF6B00CC65FD2D45A326E74492B2C19FB7682B62FR711WXCHMBA05z_-- From nobody Thu May 19 02:00:37 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8271812D12A for ; Thu, 19 May 2016 02:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 RPmluWmXX3Qi for ; Thu, 19 May 2016 02:00:34 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 8A96012D131 for ; Thu, 19 May 2016 02:00:27 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id A0694DBC3BAD6; Thu, 19 May 2016 09:00:23 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u4J90PNa021516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 May 2016 09:00:25 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u4J90IKH027261 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 May 2016 11:00:24 +0200 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.203]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Thu, 19 May 2016 11:00:19 +0200 From: "De Schepper, Koen (Nokia - BE)" To: "Scharf, Michael (Nokia - DE)" , "Bob Briscoe" , TCP Prague List Thread-Topic: [tcpPrague] Draft L4S deliverables list Thread-Index: AQHRsSERcasadcLDHUypp3oMSIJcD5++0yeAgAAvAHA= Date: Thu, 19 May 2016 09:00:18 +0000 Message-ID: References: <573C9605.8080308@bobbriscoe.net> <655C07320163294895BBADA28372AF5D4885A3C9@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D4885A3C9@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: multipart/alternative; boundary="_000_BF6B00CC65FD2D45A326E74492B2C19FB7682B75FR711WXCHMBA05z_" MIME-Version: 1.0 Archived-At: Subject: Re: [tcpPrague] Draft L4S deliverables list X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 09:00:36 -0000 --_000_BF6B00CC65FD2D45A326E74492B2C19FB7682B75FR711WXCHMBA05z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Rm9yIHRoZSBBUU0gcGFydCAoMikgd2UgaGF2ZSBydW5uaW5nIGNvZGUuIE91ciBsYXRlc3QgRHVh bFEtUEkyIHN1cHBvcnRzIGJvdGggZWN0KDApIGFuZCBlY3QoMSksIGRvaW5nIGNsYXNzaWMgZWNu IGFuZCBMNFMgZWNuIHJlc3BlY3RpdmVseSAoY292ZXJpbmcgdG9waWMgMSBmcm9tIHRoZSBuZXR3 b3JrKS4gRm9yIDMuMSwgTVMgV2luZG93cyBoYXMgcnVubmluZyBjb2RlIGFuZCB3ZSB0ZXN0ZWQg dGhhdCBpdCBpcyByZXNwb25kaW5nIGNvcnJlY3RseSB0byBkcm9wICh3ZSBkaWRu4oCZdCB0ZXN0 IEZyZWVCU0QpLiBNYXliZSBvdGhlcnMgaGF2ZSBtb3JlIGltcGxlbWVudGF0aW9ucz8NCg0KUmVn YXJkcywNCktvZW4uDQoNCg0KRnJvbTogdGNwUHJhZ3VlIFttYWlsdG86dGNwcHJhZ3VlLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTY2hhcmYsIE1pY2hhZWwgKE5va2lhIC0gREUpDQpT ZW50OiB3b2Vuc2RhZyAxOCBtZWkgMjAxNiAxOTozNA0KVG86IEJvYiBCcmlzY29lOyBUQ1AgUHJh Z3VlIExpc3QNClN1YmplY3Q6IFJlOiBbdGNwUHJhZ3VlXSBEcmFmdCBMNFMgZGVsaXZlcmFibGVz IGxpc3QNCg0KSXMgdGhlcmUgcnVubmluZyBjb2RlPw0KDQpUaHgNCg0KTWljaGFlbA0KDQoNCkZy b206IHRjcFByYWd1ZSBbbWFpbHRvOnRjcHByYWd1ZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgQm9iIEJyaXNjb2UNClNlbnQ6IFdlZG5lc2RheSwgTWF5IDE4LCAyMDE2IDY6MTkgUE0N ClRvOiBUQ1AgUHJhZ3VlIExpc3QNClN1YmplY3Q6IFt0Y3BQcmFndWVdIERyYWZ0IEw0UyBkZWxp dmVyYWJsZXMgbGlzdA0KDQpGb2xrcywNCg0KSGVyZSdzIHRoZSB0YWJsZSBvZiBwb3RlbnRpYWwg ZGVsaXZlcmFibGVzIHRoYXQgSSBwcmVzZW50ZWQgaW4gQnVlbm9zIEFpcmVzLiBJJ3ZlIHN0YXJ0 ZWQgdG8gYWRkIHZvbHVudGVlcidzIG5hbWVzLg0KUGxzIGNvbnRpbnVlLi4uDQoNCkVhY2ggc2hv dWxkIHByb2JhYmx5IGJlIGRpdmlkZWQgaW50byBpbXBsZW1lbnRhdGlvbiBhbmQgZHJhZnRpbmcg dGhlIHNwZWMsIGJ1dCBsZXQncyBhc3N1bWUgYW55IHZvbHVudGVlciB3aWxsIGRvIGJvdGgvZWl0 aGVyLg0KDQpEZXNjcmlwdGlvbg0KDQpEcmFmdChzKQ0KDQpWb2x1bnRlZXJzDQoNClRhcmdldCBX Rw0KDQoxKQ0KDQpMNFMgaWRlbnRpZmllcg0KDQpkcmFmdC1icmlzY29lLXRzdndnLWVjbi1sNHMt aWQNCg0KYXV0aG9ycyBvbiBkcmFmdA0KDQp0c3Z3Zz8NCg0KMikNCg0KVGhlIER1YWxRIEFRTQ0K DQpkcmFmdC1icmlzY29lLWFxbS1kdWFscS1jb3VwbGVkDQoNCmF1dGhvcnMgb24gZHJhZnQNCg0K YXFtPw0KDQoNCjMpDQoNClNjYWxhYmxlIFRyYW5zcG9ydA0KDQozLTEpDQoNCkZhbGwgYmFjayB0 byBSZW5vL0N1YmljIG9uIGxvc3MNCg0KTGludXggLyB0Y3BtDQoNCjMtMikNCg0KVENQIEVDTiBG ZWVkYmFjaw0KDQpkcmFmdC1pZXRmLXRjcG0tYWNjdXJhdGUtZWNuDQoNCmF1dGhvcnMgb24gZHJh ZnQNCg0KdGNwbQ0KDQozLTQpDQoNClNjYWxpbmcgVENQJ3MgQ29uZ2VzdGlvbiBXaW5kb3cgZm9y IFNtYWxsIFJvdW5kIFRyaXAgVGltZXMNCg0KQm9iIEJyaXNjb2UsIE1hcmNlbG8gQmFnbnVsbyBC cmF1bg0KDQp0Y3BtPw0KDQozLTUpDQoNClJlZHVjZSBUQ1AgLyBTQ1RDUCAvIFRDUCBQcmFndWUg UlRULWRlcGVuZGVuY2UNCg0KdGNwbT8NCg0KMy02KQ0KDQpTbW9vdGggRUNOIGZlZWRiYWNrIG92 ZXIgZmxvdydzIFJUVCwgbm90IFJUVCBoYXJkLWNvZGVkIGZvciBEQw0KDQp0Y3BtPw0KDQozLTcp DQoNCkZhbGwgYmFjayB0byBSZW5vL0N1YmljIGlmIGNsYXNzaWMgRUNOIGJvdHRsZW5lY2sgZGV0 ZWN0ZWQNCg0KdGNwbT8NCg0KMy04KQ0KDQpGYXN0ZXItdGhhbi1hZGRpdGl2ZSBpbmNyZWFzZQ0K DQpNYXJjZWxvDQoNCnRjcG0/DQoNCjMtOSkNCg0KTGVzcyBkcmFzdGljIGV4aXQgZnJvbSBzbG93 LXN0YXJ0DQoNCk1hcmNlbG8sIEJvYg0KDQp0Y3BtPw0KDQoNCjQpDQoNCuKAnFRDUCBQcmFndWXi gJ0gKGZvciB0aGUgSW50ZXJuZXQpDQoNCnRjcG0/DQoNCjUpDQoNCkRDVENQIGJpcyAoZm9yIGRh dGEgY2VudHJlcyAtIG1heSBiZSB0aGUgc2FtZSBhcyBUQ1AgUHJhZ3VlKQ0KDQpkcmFmdC1pZXRm LXRjcG0tZGN0Y3AgKGJpcykNCg0KdGNwbT8NCg0KNikNCg0KIlNDVFAgUHJhZ3VlIg0KDQp0Y3Bt L3RzdndnPw0KDQo3KQ0KDQrigJxSTUNBVCBQcmFndWXigJ0NCg0Kcm1jYXQ/DQoNCg0KTm90ZXM6 DQpBIGxpbmUgY2FuIGJlIGRyYXduIHNvbWV3aGVyZSBhcm91bmQgMy03KSB0byBpbmRpY2F0ZSB0 aGF0IGV2ZXJ5dGhpbmcgYWJvdmUgaXMgYW4gZXNzZW50aWFsIHNhZmV0eSBmZWF0dXJlIChwcmV2 ZW50aW5nIHN0YXJ2YXRpb24gZXRjKSwgd2hpbGUgZXZlcnl0aGluZyBiZWxvdyAodXAgdG8gMy05 KSBpcyBhIHBlcmZvcm1hbmNlIGltcHJvdmVtZW50Lg0KDQo0LDUsNikgYXJlIGVzc2VudGlhbGx5 IHdyYXAtdXBzIG9mIHRoZSByZWxldmFudCBlbGVtZW50cyBmcm9tIDMtMSkgdG8gMy05KSBmb3Ig ZWFjaCBkaWZmZXJlbnQgdHJhbnNwb3J0DQo3KSBtaWdodCByZXF1aXJlIG9uZSBkcmFmdCBmb3Ig TmFkYSwgb25lIGZvciBTQ1JFQU0sIGV0YyBvciBpdCBtaWdodCBiZSBwb3NzaWJsZSB0byBkZXNj cmliZSBvbmUgc2ltcGxlIGRlbHRhIGZvciBhbGwgUk1DQVQgYXBwcm9hY2hlcy4NCg0KV2hldGhl ciB3ZSBuZWVkIGFsbCB0aGUgYml0dHkgcGllY2VzIDMtMSkgdG8gMy05KSBvciB3aGV0aGVyIHdl IHNob3VsZCBnbyBzdHJhaWdodCBmb3IgdGhlIHdyYXAtdXAgc29sdXRpb25zLCBpcyB1cCBmb3Ig ZGlzY3Vzc2lvbi4NCg0KDQpCb2INCg0KDQoNCi0tDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KQm9iIEJyaXNjb2Ug ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaHR0cDovL2JvYmJyaXNjb2UubmV0Lw0K --_000_BF6B00CC65FD2D45A326E74492B2C19FB7682B75FR711WXCHMBA05z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToi Q291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0 ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1z dHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpD b25zb2xhczsNCgljb2xvcjpibGFjazt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj MUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29u IFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjpibGFjazt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQg NzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xv cj0id2hpdGUiIGxhbmc9Ik5MLUJFIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZvciB0aGUgQVFNIHBh cnQgKDIpIHdlIGhhdmUgcnVubmluZyBjb2RlLiBPdXIgbGF0ZXN0IER1YWxRLVBJMiBzdXBwb3J0 cyBib3RoIGVjdCgwKSBhbmQgZWN0KDEpLCBkb2luZyBjbGFzc2ljIGVjbiBhbmQgTDRTIGVjbiBy ZXNwZWN0aXZlbHkgKGNvdmVyaW5nDQogdG9waWMgMSBmcm9tIHRoZSBuZXR3b3JrKS4gRm9yIDMu MSwgTVMgV2luZG93cyBoYXMgcnVubmluZyBjb2RlIGFuZCB3ZSB0ZXN0ZWQgdGhhdCBpdCBpcyBy ZXNwb25kaW5nIGNvcnJlY3RseSB0byBkcm9wICh3ZSBkaWRu4oCZdCB0ZXN0IEZyZWVCU0QpLiBN YXliZSBvdGhlcnMgaGF2ZSBtb3JlIGltcGxlbWVudGF0aW9ucz88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPktvZW4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZy b206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6d2luZG93dGV4dCI+IHRjcFByYWd1ZSBbbWFpbHRvOnRjcHByYWd1ZS1ib3VuY2VzQGlldGYu b3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5TY2hhcmYsIE1pY2hhZWwgKE5va2lhIC0gREUpPGJy Pg0KPGI+U2VudDo8L2I+IHdvZW5zZGFnIDE4IG1laSAyMDE2IDE5OjM0PGJyPg0KPGI+VG86PC9i PiBCb2IgQnJpc2NvZTsgVENQIFByYWd1ZSBMaXN0PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb dGNwUHJhZ3VlXSBEcmFmdCBMNFMgZGVsaXZlcmFibGVzIGxpc3Q8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklzIHRoZXJlIHJ1bm5pbmcgY29kZT88bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGh4PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPk1pY2hhZWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20g MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiB0Y3BQcmFn dWUgWzxhIGhyZWY9Im1haWx0bzp0Y3BwcmFndWUtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnRj cHByYWd1ZS1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Qm9iIEJy aXNjb2U8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBNYXkgMTgsIDIwMTYgNjoxOSBQTTxi cj4NCjxiPlRvOjwvYj4gVENQIFByYWd1ZSBMaXN0PGJyPg0KPGI+U3ViamVjdDo8L2I+IFt0Y3BQ cmFndWVdIERyYWZ0IEw0UyBkZWxpdmVyYWJsZXMgbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Rm9sa3MsPGJyPg0KPGJy Pg0KSGVyZSdzIHRoZSB0YWJsZSBvZiBwb3RlbnRpYWwgZGVsaXZlcmFibGVzIHRoYXQgSSBwcmVz ZW50ZWQgaW4gQnVlbm9zIEFpcmVzLiBJJ3ZlIHN0YXJ0ZWQgdG8gYWRkIHZvbHVudGVlcidzIG5h bWVzLg0KPGJyPg0KUGxzIGNvbnRpbnVlLi4uPGJyPg0KPGJyPg0KRWFjaCBzaG91bGQgcHJvYmFi bHkgYmUgZGl2aWRlZCBpbnRvIGltcGxlbWVudGF0aW9uIGFuZCBkcmFmdGluZyB0aGUgc3BlYywg YnV0IGxldCdzIGFzc3VtZSBhbnkgdm9sdW50ZWVyIHdpbGwgZG8gYm90aC9laXRoZXIuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIw IiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjEwMCUiIHN0eWxlPSJ3aWR0aDoxMDAuMCUiPg0KPHRi b2R5Pg0KPHRyPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAx LjVwdCAxLjVwdCI+PC90ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQg MS41cHQgMS41cHQgMS41cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RGVzY3JpcHRpb248 L2I+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGlu ZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5EcmFm dChzKTwvYj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJw YWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PlZvbHVudGVlcnM8L2I+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBz dHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj5UYXJnZXQgV0c8L2I+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4N Cjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQgMS41cHQgMS41cHQgMS41cHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MSk8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgdmFs aWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkw0UyBpZGVudGlmaWVyPG86cD48L286cD48L3A+DQo8L3RkPg0KPHRk IHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5kcmFmdC1icmlzY29lLXRzdndnLWVjbi1sNHMtaWQ8bzpwPjwv bzpwPjwvcD4NCjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjEuNXB0IDEu NXB0IDEuNXB0IDEuNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmF1dGhvcnMgb24gZHJhZnQ8 bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjEu NXB0IDEuNXB0IDEuNXB0IDEuNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRzdndnPzxvOnA+ PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJw YWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIp PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzox LjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgRHVhbFEg QVFNPG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGlu ZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5kcmFmdC1i cmlzY29lLWFxbS1kdWFscS1jb3VwbGVkPG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHZhbGln bj0idG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5hdXRob3JzIG9uIGRyYWZ0PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRk IHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5hcW0/PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0 cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQgMS41cHQgMS41cHQgMS41 cHQiPjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEu NXB0IDEuNXB0Ij48L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAx LjVwdCAxLjVwdCAxLjVwdCI+PC90ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6 MS41cHQgMS41cHQgMS41cHQgMS41cHQiPjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJw YWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0Ij48L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCB2 YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQgMS41cHQgMS41cHQgMS41cHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+Myk8L2I+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHZh bGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj5TY2FsYWJsZSBUcmFuc3BvcnQ8L2I+PG86cD48L286cD48L3A+ DQo8L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVw dCAxLjVwdCI+PC90ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQgMS41 cHQgMS41cHQgMS41cHQiPjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjEu NXB0IDEuNXB0IDEuNXB0IDEuNXB0Ij48L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCB2YWxpZ249InRv cCIgc3R5bGU9InBhZGRpbmc6MS41cHQgMS41cHQgMS41cHQgMS41cHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+My0xKTxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5 bGU9InBhZGRpbmc6MS41cHQgMS41cHQgMS41cHQgMS41cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+RmFsbCBiYWNrIHRvIFJlbm8vQ3ViaWMgb24gbG9zczxvOnA+PC9vOnA+PC9wPg0KPC90ZD4N Cjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQgMS41cHQgMS41cHQgMS41cHQi PjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0 IDEuNXB0Ij48L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVw dCAxLjVwdCAxLjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5MaW51eCAvIHRjcG08bzpwPjwv bzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFk ZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4zLTIp PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzox LjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UQ1AgRUNOIEZl ZWRiYWNrPG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFk ZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5kcmFm dC1pZXRmLXRjcG0tYWNjdXJhdGUtZWNuPG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHZhbGln bj0idG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5hdXRob3JzIG9uIGRyYWZ0PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRk IHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj50Y3BtPG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0 cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQgMS41cHQgMS41cHQgMS41 cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+My00KTxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0 ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQgMS41cHQgMS41cHQgMS41cHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+U2NhbGluZyBUQ1AncyBDb25nZXN0aW9uIFdpbmRvdyBmb3Ig U21hbGwgUm91bmQgVHJpcCBUaW1lczxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB2YWxpZ249 InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQgMS41cHQgMS41cHQgMS41cHQiPjwvdGQ+DQo8dGQg dmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkJvYiBCcmlzY29lLCBNYXJjZWxvIEJhZ251bG8gQnJhdW48bzpw PjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjEuNXB0 IDEuNXB0IDEuNXB0IDEuNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRjcG0/PG86cD48L286 cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRp bmc6MS41cHQgMS41cHQgMS41cHQgMS41cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+My01KTxv OnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41 cHQgMS41cHQgMS41cHQgMS41cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVkdWNlIFRDUCAv IFNDVENQIC8gVENQIFByYWd1ZSBSVFQtZGVwZW5kZW5jZTxvOnA+PC9vOnA+PC9wPg0KPC90ZD4N Cjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQgMS41cHQgMS41cHQgMS41cHQi PjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0 IDEuNXB0Ij48L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVw dCAxLjVwdCAxLjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50Y3BtPzxvOnA+PC9vOnA+PC9w Pg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjEu NXB0IDEuNXB0IDEuNXB0IDEuNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjMtNik8bzpwPjwv bzpwPjwvcD4NCjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjEuNXB0IDEu NXB0IDEuNXB0IDEuNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNtb290aCBFQ04gZmVlZGJh Y2sgb3ZlciBmbG93J3MgUlRULCBub3QgUlRUIGhhcmQtY29kZWQgZm9yIERDPG86cD48L286cD48 L3A+DQo8L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAx LjVwdCAxLjVwdCI+PC90ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQg MS41cHQgMS41cHQgMS41cHQiPjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5n OjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRjcG0/PG86 cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9 InBhZGRpbmc6MS41cHQgMS41cHQgMS41cHQgMS41cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ My03KTxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRp bmc6MS41cHQgMS41cHQgMS41cHQgMS41cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RmFsbCBi YWNrIHRvIFJlbm8vQ3ViaWMgaWYgY2xhc3NpYyBFQ04gYm90dGxlbmVjayBkZXRlY3RlZDxvOnA+ PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQg MS41cHQgMS41cHQgMS41cHQiPjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5n OjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0Ij48L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0i cGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50 Y3BtPzxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgdmFsaWduPSJ0b3Ai IHN0eWxlPSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjMtOCk8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxl PSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkZhc3Rlci10aGFuLWFkZGl0aXZlIGluY3JlYXNlPG86cD48L286cD48L3A+DQo8L3RkPg0KPHRk IHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+PC90 ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQgMS41cHQgMS41cHQgMS41 cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWFyY2VsbzxvOnA+PC9vOnA+PC9wPg0KPC90ZD4N Cjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQgMS41cHQgMS41cHQgMS41cHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGNwbT88bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3Ry Pg0KPHRyPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVw dCAxLjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4zLTkpPG86cD48L286cD48L3A+DQo8L3Rk Pg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5MZXNzIGRyYXN0aWMgZXhpdCBmcm9tIHNsb3ctc3Rh cnQ8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5n OjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0Ij48L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0i cGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5N YXJjZWxvLCBCb2I8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxl PSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PnRjcG0/PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCB2YWxpZ249InRv cCIgc3R5bGU9InBhZGRpbmc6MS41cHQgMS41cHQgMS41cHQgMS41cHQiPjwvdGQ+DQo8dGQgdmFs aWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0Ij48L3RkPg0K PHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+ PC90ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQgMS41cHQgMS41cHQg MS41cHQiPjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjEuNXB0IDEuNXB0 IDEuNXB0IDEuNXB0Ij48L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9 InBhZGRpbmc6MS41cHQgMS41cHQgMS41cHQgMS41cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ NCk8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5n OjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKAnFRDUCBQ cmFndWXigJ0gKGZvciB0aGUgSW50ZXJuZXQpPG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHZh bGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+PC90ZD4N Cjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQgMS41cHQgMS41cHQgMS41cHQi PjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0 IDEuNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRjcG0/PG86cD48L286cD48L3A+DQo8L3Rk Pg0KPC90cj4NCjx0cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQgMS41 cHQgMS41cHQgMS41cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+NSk8bzpwPjwvbzpwPjwvcD4N CjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0 IDEuNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRDVENQIGJpcyAoZm9yIGRhdGEgY2VudHJl cyAtIG1heSBiZSB0aGUgc2FtZSBhcyBUQ1AgUHJhZ3VlKTxvOnA+PC9vOnA+PC9wPg0KPC90ZD4N Cjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQgMS41cHQgMS41cHQgMS41cHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ZHJhZnQtaWV0Zi10Y3BtLWRjdGNwIChiaXMpPG86cD48 L286cD48L3A+DQo8L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAx LjVwdCAxLjVwdCAxLjVwdCI+PC90ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6 MS41cHQgMS41cHQgMS41cHQgMS41cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGNwbT88bzpw PjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0i cGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj42 KTxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6 MS41cHQgMS41cHQgMS41cHQgMS41cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JnF1b3Q7U0NU UCBQcmFndWUmcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0 eWxlPSJwYWRkaW5nOjEuNXB0IDEuNXB0IDEuNXB0IDEuNXB0Ij48L3RkPg0KPHRkIHZhbGlnbj0i dG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVwdCAxLjVwdCI+PC90ZD4NCjx0ZCB2 YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQgMS41cHQgMS41cHQgMS41cHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+dGNwbS90c3Z3Zz88bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3Ry Pg0KPHRyPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVw dCAxLjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj43KTxvOnA+PC9vOnA+PC9wPg0KPC90ZD4N Cjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQgMS41cHQgMS41cHQgMS41cHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+4oCcUk1DQVQgUHJhZ3Vl4oCdPG86cD48L286cD48L3A+ DQo8L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzoxLjVwdCAxLjVwdCAxLjVw dCAxLjVwdCI+PC90ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MS41cHQgMS41 cHQgMS41cHQgMS41cHQiPjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjEu NXB0IDEuNXB0IDEuNXB0IDEuNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnJtY2F0PzxvOnA+ PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMi Pjxicj4NCjxiPk5vdGVzOjxicj4NCjwvYj5BIGxpbmUgY2FuIGJlIGRyYXduIHNvbWV3aGVyZSBh cm91bmQgMy03KSB0byBpbmRpY2F0ZSB0aGF0IGV2ZXJ5dGhpbmcgYWJvdmUgaXMgYW4gZXNzZW50 aWFsIHNhZmV0eSBmZWF0dXJlIChwcmV2ZW50aW5nIHN0YXJ2YXRpb24gZXRjKSwgd2hpbGUgZXZl cnl0aGluZyBiZWxvdyAodXAgdG8gMy05KSBpcyBhIHBlcmZvcm1hbmNlIGltcHJvdmVtZW50Ljxi cj4NCjxicj4NCjQsNSw2KSBhcmUgZXNzZW50aWFsbHkgd3JhcC11cHMgb2YgdGhlIHJlbGV2YW50 IGVsZW1lbnRzIGZyb20gMy0xKSB0byAzLTkpIGZvciBlYWNoIGRpZmZlcmVudCB0cmFuc3BvcnQ8 YnI+DQo3KSBtaWdodCByZXF1aXJlIG9uZSBkcmFmdCBmb3IgTmFkYSwgb25lIGZvciBTQ1JFQU0s IGV0YyBvciBpdCBtaWdodCBiZSBwb3NzaWJsZSB0byBkZXNjcmliZSBvbmUgc2ltcGxlIGRlbHRh IGZvciBhbGwgUk1DQVQgYXBwcm9hY2hlcy48YnI+DQo8YnI+DQpXaGV0aGVyIHdlIG5lZWQgYWxs IHRoZSBiaXR0eSBwaWVjZXMgMy0xKSB0byAzLTkpIG9yIHdoZXRoZXIgd2Ugc2hvdWxkIGdvIHN0 cmFpZ2h0IGZvciB0aGUgd3JhcC11cCBzb2x1dGlvbnMsIGlzIHVwIGZvciBkaXNjdXNzaW9uLjxi cj4NCjxicj4NCjxicj4NCkJvYjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyA8YnI+DQombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHByZT48c3BhbiBsYW5n PSJFTi1VUyI+LS0gPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVO LVVTIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVO LVVTIj5Cb2IgQnJpc2NvZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwOi8vYm9iYnJpc2NvZS5uZXQv Ij5odHRwOi8vYm9iYnJpc2NvZS5uZXQvPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BF6B00CC65FD2D45A326E74492B2C19FB7682B75FR711WXCHMBA05z_-- From nobody Thu May 19 03:55:13 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 228DA12D91E for ; Thu, 19 May 2016 03:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 Tt2B6QC0LwcO for ; Thu, 19 May 2016 03:55:09 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 5CF7D12D906 for ; Thu, 19 May 2016 03:55:05 -0700 (PDT) Received: from 173.7.199.146.dyn.plus.net ([146.199.7.173]:39129 helo=[192.168.0.10]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1b3Lba-0002CK-Qu; Thu, 19 May 2016 11:55:03 +0100 To: "De Schepper, Koen (Nokia - BE)" , "Scharf, Michael (Nokia - DE)" References: <573C9605.8080308@bobbriscoe.net> <655C07320163294895BBADA28372AF5D4885A3C9@FR712WXCHMBA15.zeu.alcatel-lucent.com> From: Bob Briscoe Message-ID: <573D9B85.1000207@bobbriscoe.net> Date: Thu, 19 May 2016 11:55:01 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------030200090906070206060300" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Cc: TCP Prague List Subject: Re: [tcpPrague] Draft L4S deliverables list X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 10:55:12 -0000 This is a multi-part message in MIME format. --------------030200090906070206060300 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Michael, Koen, all, Could people give a URL for any open source code (or failing that, binaries). Then I will add a link to this list: https://riteproject.eu/dctth/#code In addition to Koen's list, you will see there a link to Mirja's TCP AccECN code. It may not have been clear from what Koen said, but DCTCP as-is{Note 1} already "works" alongside Classic TCP on the public Internet with either of the AQMs Koen has implemented{Note 2}. However, the definition of "works" is currently good enough for performance and functional testing of DCTCP alongside Classic TCP, but not sufficient for full safety in all circumstances. Items 3-1) to 3-7) address safety in the various specific cases described. The phrase "TCP Prague" is being used for a (currently hypothetical) TCP that implements sufficient of these features to be safe for use on the public Internet. One aim is for the IETF to determine which of these safety features are MUSTs, which are SHOULDs, etc. Bob {Note 1}: Tested with Linux and Windows versions of DCTCP {Note 2}: With either Curvy RED or PI2 as the AQM for Classic traffic. On 19/05/16 10:00, De Schepper, Koen (Nokia - BE) wrote: > > For the AQM part (2) we have running code. Our latest DualQ-PI2 > supports both ect(0) and ect(1), doing classic ecn and L4S ecn > respectively (covering topic 1 from the network). For 3.1, MS Windows > has running code and we tested that it is responding correctly to drop > (we didnt test FreeBSD). Maybe others have more implementations? > > Regards, > > Koen. > > *From:*tcpPrague [mailto:tcpprague-bounces@ietf.org] *On Behalf Of > *Scharf, Michael (Nokia - DE) > *Sent:* woensdag 18 mei 2016 19:34 > *To:* Bob Briscoe; TCP Prague List > *Subject:* Re: [tcpPrague] Draft L4S deliverables list > > Is there running code? > > Thx > > Michael > > *From:*tcpPrague [mailto:tcpprague-bounces@ietf.org] *On Behalf Of > *Bob Briscoe > *Sent:* Wednesday, May 18, 2016 6:19 PM > *To:* TCP Prague List > *Subject:* [tcpPrague] Draft L4S deliverables list > > Folks, > > Here's the table of potential deliverables that I presented in Buenos > Aires. I've started to add volunteer's names. > Pls continue... > > Each should probably be divided into implementation and drafting the > spec, but let's assume any volunteer will do both/either. > > > > > *Description* > > > > *Draft(s)* > > > > *Volunteers* > > > > *Target WG* > > 1) > > > > L4S identifier > > > > draft-briscoe-tsvwg-ecn-l4s-id > > > > authors on draft > > > > tsvwg? > > 2) > > > > The DualQ AQM > > > > draft-briscoe-aqm-dualq-coupled > > > > authors on draft > > > > aqm? > > > > > > > > *3)* > > > > *Scalable Transport* > > > > > > 3-1) > > > > Fall back to Reno/Cubic on loss > > > > > > Linux / tcpm > > 3-2) > > > > TCP ECN Feedback > > > > draft-ietf-tcpm-accurate-ecn > > > > authors on draft > > > > tcpm > > 3-4) > > > > Scaling TCP's Congestion Window for Small Round Trip Times > > > > > Bob Briscoe, Marcelo Bagnulo Braun > > > > tcpm? > > 3-5) > > > > Reduce TCP / SCTCP / TCP Prague RTT-dependence > > > > > > tcpm? > > 3-6) > > > > Smooth ECN feedback over flow's RTT, not RTT hard-coded for DC > > > > > > tcpm? > > 3-7) > > > > Fall back to Reno/Cubic if classic ECN bottleneck detected > > > > > > tcpm? > > 3-8) > > > > Faster-than-additive increase > > > > > Marcelo > > > > tcpm? > > 3-9) > > > > Less drastic exit from slow-start > > > > > Marcelo, Bob > > > > tcpm? > > > > > > > > 4) > > > > TCP Prague (for the Internet) > > > > > > tcpm? > > 5) > > > > DCTCP bis (for data centres - may be the same as TCP Prague) > > > > draft-ietf-tcpm-dctcp (bis) > > > > > tcpm? > > 6) > > > > "SCTP Prague" > > > > > > tcpm/tsvwg? > > 7) > > > > RMCAT Prague > > > > > > rmcat? > > > *Notes: > *A line can be drawn somewhere around 3-7) to indicate that everything > above is an essential safety feature (preventing starvation etc), > while everything below (up to 3-9) is a performance improvement. > > 4,5,6) are essentially wrap-ups of the relevant elements from 3-1) to > 3-9) for each different transport > 7) might require one draft for Nada, one for SCREAM, etc or it might > be possible to describe one simple delta for all RMCAT approaches. > > Whether we need all the bitty pieces 3-1) to 3-9) or whether we should > go straight for the wrap-up solutions, is up for discussion. > > > Bob > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------030200090906070206060300 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Michael, Koen, all,

Could people give a URL for any open source code (or failing that, binaries). Then I will add a link to this list:
https://riteproject.eu/dctth/#code
In addition to Koen's list, you will see there a link to Mirja's TCP AccECN code.

It may not have been clear from what Koen said, but DCTCP as-is{Note 1} already "works" alongside Classic TCP on the public Internet with either of the AQMs Koen has implemented{Note 2}.
However, the definition of "works" is currently good enough for performance and functional testing of DCTCP alongside Classic TCP, but not sufficient for full safety in all circumstances.
Items 3-1) to 3-7) address safety in the various specific cases described.

The phrase "TCP Prague" is being used for a (currently hypothetical) TCP that implements sufficient of these features to be safe for use on the public Internet.
One aim is for the IETF to determine which of these safety features are MUSTs, which are SHOULDs, etc.



Bob

{Note 1}: Tested with Linux and Windows versions of DCTCP
{Note 2}: With either Curvy RED or PI2 as the AQM for Classic traffic.


On 19/05/16 10:00, De Schepper, Koen (Nokia - BE) wrote:

For the AQM part (2) we have running code. Our latest DualQ-PI2 supports both ect(0) and ect(1), doing classic ecn and L4S ecn respectively (covering topic 1 from the network). For 3.1, MS Windows has running code and we tested that it is responding correctly to drop (we didnt test FreeBSD). Maybe others have more implementations?

Regards,

Koen.

From: tcpPrague [mailto:tcpprague-bounces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: woensdag 18 mei 2016 19:34
To: Bob Briscoe; TCP Prague List
Subject: Re: [tcpPrague] Draft L4S deliverables list

Is there running code?

Thx

Michael

From: tcpPrague [mailto:tcpprague-bounces@ietf.org] On Behalf Of Bob Briscoe
Sent: Wednesday, May 18, 2016 6:19 PM
To: TCP Prague List
Subject: [tcpPrague] Draft L4S deliverables list

Folks,

Here's the table of potential deliverables that I presented in Buenos Aires. I've started to add volunteer's names.
Pls continue...

Each should probably be divided into implementation and drafting the spec, but let's assume any volunteer will do both/either.

Description

Draft(s)

Volunteers

Target WG

1)

L4S identifier

draft-briscoe-tsvwg-ecn-l4s-id

authors on draft

tsvwg?

2)

The DualQ AQM

draft-briscoe-aqm-dualq-coupled

authors on draft

aqm?





3)

Scalable Transport


3-1)

Fall back to Reno/Cubic on loss

Linux / tcpm

3-2)

TCP ECN Feedback

draft-ietf-tcpm-accurate-ecn

authors on draft

tcpm

3-4)

Scaling TCP's Congestion Window for Small Round Trip Times

Bob Briscoe, Marcelo Bagnulo Braun

tcpm?

3-5)

Reduce TCP / SCTCP / TCP Prague RTT-dependence

tcpm?

3-6)

Smooth ECN feedback over flow's RTT, not RTT hard-coded for DC

tcpm?

3-7)

Fall back to Reno/Cubic if classic ECN bottleneck detected

tcpm?

3-8)

Faster-than-additive increase

Marcelo

tcpm?

3-9)

Less drastic exit from slow-start

Marcelo, Bob

tcpm?





4)

TCP Prague (for the Internet)

tcpm?

5)

DCTCP bis (for data centres - may be the same as TCP Prague)

draft-ietf-tcpm-dctcp (bis)

tcpm?

6)

"SCTP Prague"

tcpm/tsvwg?

7)

RMCAT Prague

rmcat?


Notes:
A line can be drawn somewhere around 3-7) to indicate that everything above is an essential safety feature (preventing starvation etc), while everything below (up to 3-9) is a performance improvement.

4,5,6) are essentially wrap-ups of the relevant elements from 3-1) to 3-9) for each different transport
7) might require one draft for Nada, one for SCREAM, etc or it might be possible to describe one simple delta for all RMCAT approaches.

Whether we need all the bitty pieces 3-1) to 3-9) or whether we should go straight for the wrap-up solutions, is up for discussion.


Bob

-- 
________________________________________________________________
Bob Briscoe http://bobbriscoe.net/

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------030200090906070206060300-- From nobody Thu May 19 04:29:16 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3F212D9AF for ; Thu, 19 May 2016 04:29:14 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 A7V_00Yx5PYY for ; Thu, 19 May 2016 04:29:12 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 6163A12D9B5 for ; Thu, 19 May 2016 04:29:12 -0700 (PDT) Received: from 173.7.199.146.dyn.plus.net ([146.199.7.173]:39166 helo=[192.168.0.10]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1b3M8c-0005ow-HH; Thu, 19 May 2016 12:29:10 +0100 To: John Leslie References: <573C564E.1090201@bobbriscoe.net> <20160518170612.GA56178@verdi> From: Bob Briscoe Message-ID: <573DA385.8020703@bobbriscoe.net> Date: Thu, 19 May 2016 12:29:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160518170612.GA56178@verdi> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Cc: TCP Prague List Subject: Re: [tcpPrague] Volunteers pls: L4S non-WG-forming BoF proposal cut-off approaching X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 11:29:14 -0000 John, On 18/05/16 18:06, John Leslie wrote: > Bob Briscoe wrote: >> At the Low Latency, Low Loss Scalable throughput (L4S) Bar Bof in Buenos >> Aires, there was support for a BoF about L4S, In the IETF-96 (Berlin) >> time-frame. >> It was decided to initially use this ML, even tho the scope of L4S is >> wider than TCP Prague. >> Consensus was to aim for a non-WG-forming BoF, to demonstrate >> willingness to work on the pieces in existing IETF WGs, and to >> co-ordinate approaches to each WG. > I'm not sure we're all convinced this work _can_ be done by the existing > WGs -- if it can, I'm all for that. I don't think it is such a problem for AQM and tsvwg. The biggest question-mark is over tcpm. One of the reasons for showing the full list of possible work (even tho some isn't even started) is to: * expose the potential load on tcpm {Note 1} * enable discussion on whether the phrase "minor" in tcpm's charter would need to be nuanced to encompass minor changes that have major effects {Note 1} Some of the deliverables would be brought to tcpm anyway, because they are important for all TCP-derived congestion controls, not just "TCP Prague". For instance, the following two RTT-related items are particularly important for L4S/"TCP Prague", but they are also important updates to the base TCP cc [RFC5681] too. 3-4) Scaling TCP's Congestion Window for Small Round Trip Times 3-5) Reduce TCP / SCTCP / TCP Prague RTT-dependence > >> To organise a successful BoF (referring to rfc5434 >> ), we need volunteers for the >> following tasks: >> #/ Draft a statement of problem & scope >> #/ List planned deliverables (incl. implementation, spec drafting), >> milestones and target WG (also identify any critical interdependencies) >> #/ Identify and draft any necessary changes to WG charters, to cover the >> above deliverables >> #/ Discuss with relevant WG chairs and ADs [see background below] >> #/ Identify volunteers (pref before the BoF) planning to work on each >> deliverable > I'll volunteer for almost anything except going to Berlin... Thanks. Can you be more specific? One thing you might immediately be able to help with: advice on formal procedure... Normally, a WG-forming BOF proposes a charter. Is it appropriate for a BoF to propose a co-ordinated set of charter deltas across multiple existing WGs? Or would it be more normal/polite/effective to propose/agree those changes in each WG? Or would the best approach be to propose the changes in the BoF, then discuss/agree each change in each WG as well? (I already understand that the IESG formally approves any charter changes.) Cheers Bob > > -- > John Leslie -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Thu May 19 04:43:17 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5964E12D9F9 for ; Thu, 19 May 2016 04:43:15 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 QTJcBGIn-3NH for ; Thu, 19 May 2016 04:43:13 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 7C87D12D9F7 for ; Thu, 19 May 2016 04:43:13 -0700 (PDT) Received: from 173.7.199.146.dyn.plus.net ([146.199.7.173]:39177 helo=[192.168.0.10]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1b3MMB-0007Ao-LZ; Thu, 19 May 2016 12:43:11 +0100 To: marcelo bagnulo braun , tcpprague@ietf.org References: <573C564E.1090201@bobbriscoe.net> <573CC0EB.6060306@it.uc3m.es> From: Bob Briscoe Message-ID: <573DA6CE.6080906@bobbriscoe.net> Date: Thu, 19 May 2016 12:43:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <573CC0EB.6060306@it.uc3m.es> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tcpPrague] Volunteers pls: L4S non-WG-forming BoF proposal cut-off approaching X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 11:43:15 -0000 Marcelo, Thanks for the offers. I didn't say what I myself would volunteer for: #1 I'd be happy to work with you and Koen (and others) on a problem statement - this is always tough, and I believe we've nailed the problem better through writing the existing drafts and a few papers on L4S. #2 Deliverables list : Already in progress (see "Subject: Draft L4S Deliverables List") #5 List volunteers for deliverables : Already in progress (see "Subject: Draft L4S Deliverables List") I could do the following but only if no-one else volunteers: #3 Changes to charters: (but I'm more than happy for others to take this on) #4 As I said, I started this, but I'm happy for others to adopt a WG each. Bob On 18/05/16 20:22, marcelo bagnulo braun wrote: > Hi, > > I am happy to help with #1, #2 and support you with any any of the > formalities > > Regards, marcelo > > > El 18/05/16 a las 13:47, Bob Briscoe escribi: >> Folks, >> >> At the Low Latency, Low Loss Scalable throughput (L4S) Bar Bof in >> Buenos Aires, there was support for a BoF about L4S, In the IETF-96 >> (Berlin) time-frame. >> It was decided to initially use this ML, even tho the scope of L4S is >> wider than TCP Prague. >> Consensus was to aim for a non-WG-forming BoF, to demonstrate >> willingness to work on the pieces in existing IETF WGs, and to >> co-ordinate approaches to each WG. >> >> The cut-off is now 2.5 weeks away. >> *2016-06-03 (Friday):* Cut-off date for BOF proposal requests to Area >> Directors at UTC 23:59. >> >> To organise a successful BoF (referring to rfc5434 >> ), we need volunteers for the >> following tasks: >> 1/ Draft a statement of problem & scope >> 2/ List planned deliverables (incl. implementation, spec drafting), >> milestones and target WG (also identify any critical interdependencies) >> 3/ Identify and draft any necessary changes to WG charters, to cover >> the above deliverables >> 4/ Discuss with relevant WG chairs and ADs [see background below] >> 5/ Identify volunteers (pref before the BoF) planning to work on each >> deliverable >> >> Some people have already volunteered in general to help with >> arranging the BoF, but we now need to get specific. >> >> Let's get volunteers for the above priority tasks first, but for >> completeness I'll also list the formalities we have to do: >> #/ Decide on name of BoF (and mailing list) >> #/ BoF facilitators - chairs, scribes, etc >> #/ Draft the BoF agenda, incl. time constraints >> #/ Decide on the BoF questions >> #/ Estimate attendance, list conflicts, decide duration >> #/ Submit a formal request for the BoF via >> http://www.ietf.org/instructions/MTG-SLOTS.html and >> http://www.ietf.org/ietf/1bof-procedures.txt >> >> I'll start off co-ordinating and chasing all the above, but contact >> me if you would like to take on the co-ordinating task. >> >> *Background work so far** >> * >> The idea of this BoF has been floated with WG chairs and ADs for some >> time now (since Nov'15 in Yokohama), except AFAIK, we haven't talked >> with the RMCAT chairs. >> Also we have already done considerable work on defining the problem >> while writing various drafts and papers about L4S. >> >> But, that was just a small group of co-authors (me, Koen, Inton, >> Olga). There's still a lot to do to build wider consensus. >> We can go ahead with a BoF scheduling request even if disagreements >> on scope/problem remain. >> But before the BoF itself, we need to have any such disagreements >> ironed out. >> >> At the Buenos Aires Bar Bof, we put up a todo list of pieces that >> will need to be worked on: >> See http://www.bobbriscoe.net/presents/1604ietf/1604-l4s-bar-bof.pdf >> particularly slides 9 & 10 >> and the target WGs for each were: >> * TSVWG (the L4S identifier) >> * AQM (the AQM - the name gives the clue ;) >> * TCPM (the DCTCP-like congestion control, covering SCTP) >> * RMCAT (L4S variants of real-time congestion controls, or at least >> standardise existing controls using the identifier) >> >> I believe, formally, each WG has to decide to charter additional work >> on its own ML. >> >> [Since then, Ingemar has pointed out on this list that we also need >> to get AQM & ECN-marking in radio networks, and that will require >> working with/through other SDOs and/or developer groups that deal >> with the MAC layer . >> V. important, but let's push that to a separate thread.] >> >> Many of the pieces have their own rationale, independent of L4S. The >> idea of the BoF is to draw the bigger picture that motivates the work. >> That doesn't preclude incremental work on the pieces for those who >> are not motivated by a big picture. >> >> Cheers >> >> >> >> Bob >> -- >> ________________________________________________________________ >> Bob Briscoehttp://bobbriscoe.net/ >> >> >> _______________________________________________ >> tcpPrague mailing list >> tcpPrague@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpprague > > _______________________________________________ > tcpPrague mailing list > tcpPrague@ietf.org > https://www.ietf.org/mailman/listinfo/tcpprague -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Thu May 19 05:55:18 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E925D12DA44 for ; Thu, 19 May 2016 05:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 aIoraGqVoZvv for ; Thu, 19 May 2016 05:55:13 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 200C412DA41 for ; Thu, 19 May 2016 05:55:13 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 079FBDA21182D; Thu, 19 May 2016 12:55:09 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u4JCt6Eb021959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 May 2016 12:55:09 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u4JCsbWw022775 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 May 2016 14:55:04 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.44]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Thu, 19 May 2016 14:54:42 +0200 From: "Scharf, Michael (Nokia - DE)" To: Bob Briscoe , John Leslie Thread-Topic: [tcpPrague] Volunteers pls: L4S non-WG-forming BoF proposal cut-off approaching Thread-Index: AQHRsSekOweZM0qg7E+wev9OXkJ76J+//3uAgAA1cAA= Date: Thu, 19 May 2016 12:54:41 +0000 Message-ID: <655C07320163294895BBADA28372AF5D4885C7A9@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <573C564E.1090201@bobbriscoe.net> <20160518170612.GA56178@verdi> <573DA385.8020703@bobbriscoe.net> In-Reply-To: <573DA385.8020703@bobbriscoe.net> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: TCP Prague List Subject: Re: [tcpPrague] Volunteers pls: L4S non-WG-forming BoF proposal cut-off approaching X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 12:55:17 -0000 > The biggest question-mark is over tcpm. One of the reasons for showing th= e full list of possible work (even tho some isn't even started) is to: > * expose the potential load on tcpm {Note 1} > * enable discussion on whether the phrase "minor" in tcpm's charter would= need to be nuanced to encompass minor changes that have major effects > {Note 1} Some of the deliverables would be brought to tcpm anyway, becaus= e they are important for all TCP-derived congestion controls, not just "TCP= Prague". > For instance, the following two RTT-related items are particularly import= ant for L4S/"TCP Prague", but they are also important updates to the base T= CP cc [RFC5681] too. > 3-4) Scaling TCP's Congestion Window for Small Round Trip Times > 3-5) Reduce TCP / SCTCP / TCP Prague RTT-dependence Before speculating too much about the TCPM charter, I believe that running = code and (realistic) experimentation would be an important starting point. Michael (as individual contributor) From nobody Thu May 19 09:11:34 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1582812D55A for ; Thu, 19 May 2016 09:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 MAR6uCThka1L for ; Thu, 19 May 2016 09:11:30 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88E1712D0DC for ; Thu, 19 May 2016 09:11:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 22A0CD930D; Thu, 19 May 2016 18:11:23 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id R90iQm+TRJBq; Thu, 19 May 2016 18:11:22 +0200 (MEST) Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id D5ED4D930C; Thu, 19 May 2016 18:11:22 +0200 (MEST) To: Bob Briscoe References: <573C564E.1090201@bobbriscoe.net> <20160518170612.GA56178@verdi> <573DA385.8020703@bobbriscoe.net> From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: <573DE5A9.70808@tik.ee.ethz.ch> Date: Thu, 19 May 2016 18:11:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <573DA385.8020703@bobbriscoe.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: TCP Prague List Subject: Re: [tcpPrague] Volunteers pls: L4S non-WG-forming BoF proposal cut-off approaching X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 16:11:34 -0000 Hi Bob, hi all, On 19.05.2016 13:29, Bob Briscoe wrote: > Normally, a WG-forming BOF proposes a charter. > Is it appropriate for a BoF to propose a co-ordinated set of charter > deltas across multiple existing WGs? > Or would it be more normal/polite/effective to propose/agree those > changes in each WG? > Or would the best approach be to propose the changes in the BoF, then > discuss/agree each change in each WG as well? You don't need a charter for a non-wg-forming BoF (which anyway wouldn't make sense). However, you should have a description of the BoF (which clearly lays out the goals of the BoF/discussion that is expected at the BoF) to provide the needed information to request a BoF, see https://www.ietf.org/wg/bof-procedures.html I can also recommend to add your BoF information to the BoF wiki page: https://tools.ietf.org/bof/trac/ Template is given here: https://tools.ietf.org/bof/trac/wiki/BofExample Regarding any charter changes in other groups: these have the be discussed and decided in the respective group. I don't think it's helpful to come up with any text now, or even discuss this text during the BoF. Hope that helps! Mirja From nobody Thu May 19 09:36:49 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18C4C12DA7E for ; Thu, 19 May 2016 09:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 HdCCmmb5MYYF for ; Thu, 19 May 2016 09:36:44 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 61A7E12DA72 for ; Thu, 19 May 2016 09:36:43 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id C53299DBC8179; Thu, 19 May 2016 16:36:37 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u4JGaeMl027500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 May 2016 16:36:40 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u4JGZ18t015872 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 May 2016 18:36:37 +0200 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.203]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Thu, 19 May 2016 18:35:07 +0200 From: "De Schepper, Koen (Nokia - BE)" To: Bob Briscoe , "Scharf, Michael (Nokia - DE)" Thread-Topic: [tcpPrague] Draft L4S deliverables list Thread-Index: AQHRsSERcasadcLDHUypp3oMSIJcD5++0yeAgAAvAHCAAPPYgIAAea7Q Date: Thu, 19 May 2016 16:35:07 +0000 Message-ID: References: <573C9605.8080308@bobbriscoe.net> <655C07320163294895BBADA28372AF5D4885A3C9@FR712WXCHMBA15.zeu.alcatel-lucent.com> <573D9B85.1000207@bobbriscoe.net> In-Reply-To: <573D9B85.1000207@bobbriscoe.net> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: multipart/alternative; boundary="_000_BF6B00CC65FD2D45A326E74492B2C19FB7682CFBFR711WXCHMBA05z_" MIME-Version: 1.0 Archived-At: Cc: TCP Prague List Subject: Re: [tcpPrague] Draft L4S deliverables list X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 16:36:48 -0000 --_000_BF6B00CC65FD2D45A326E74492B2C19FB7682CFBFR711WXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, >> It may not have been clear from what Koen said, but DCTCP as-is{Note 1} = already "works" alongside Classic TCP on the public Internet with either of= the AQMs Koen has implemented{Note 2}. What I meant was that DCTCP in Windows already implements topic 3-1) "Fall = back to Reno/Cubic on loss" below. It does not yet do the other topics in 3= ), but as Bob mentioned, we should define what is required for an L4S TCP p= rotocol to run save on the internet. Personally I think at least topics 1, = 3-1, 3-2, 3-4, 3-5 and 3-7 are mandatory, and as long as they are not resol= ved, DCTCP should be used in managed/contained environments only. I think 3= -6 might be more an optimization (not sure though). Bob, 3-3 is missing, probably because you renamed that as 1, right? Note that in these managed environments DCTCP CAN already share automatical= ly and fairly the throughput with classic TCPs if DualQ is used in the main= bottlenecks. Also Windows DCTCP will work correctly (as Reno, so no L4S) i= n the legacy (drop-based) bottlenecks if they would appear, because it impl= ements 3-1). It won't work if Classic ECN is enabled in these bottlenecks, = though as 3.2 and 3.7 are not resolved yet. Hope this clarifies, Koen. From: Bob Briscoe [mailto:research@bobbriscoe.net] Sent: donderdag 19 mei 2016 12:55 To: De Schepper, Koen (Nokia - BE); Scharf, Michael (Nokia - DE) Cc: TCP Prague List Subject: Re: [tcpPrague] Draft L4S deliverables list Michael, Koen, all, Could people give a URL for any open source code (or failing that, binaries= ). Then I will add a link to this list: https://riteproject.eu/dctth/#code In addition to Koen's list, you will see there a link to Mirja's TCP AccECN= code. It may not have been clear from what Koen said, but DCTCP as-is{Note 1} alr= eady "works" alongside Classic TCP on the public Internet with either of th= e AQMs Koen has implemented{Note 2}. However, the definition of "works" is currently good enough for performanc= e and functional testing of DCTCP alongside Classic TCP, but not sufficient= for full safety in all circumstances. Items 3-1) to 3-7) address safety in the various specific cases described. The phrase "TCP Prague" is being used for a (currently hypothetical) TCP th= at implements sufficient of these features to be safe for use on the public= Internet. One aim is for the IETF to determine which of these safety features are MUS= Ts, which are SHOULDs, etc. Bob {Note 1}: Tested with Linux and Windows versions of DCTCP {Note 2}: With either Curvy RED or PI2 as the AQM for Classic traffic. On 19/05/16 10:00, De Schepper, Koen (Nokia - BE) wrote: For the AQM part (2) we have running code. Our latest DualQ-PI2 supports bo= th ect(0) and ect(1), doing classic ecn and L4S ecn respectively (covering = topic 1 from the network). For 3.1, MS Windows has running code and we test= ed that it is responding correctly to drop (we didn't test FreeBSD). Maybe = others have more implementations? Regards, Koen. From: tcpPrague [mailto:tcpprague-bounces@ietf.org] On Behalf Of Scharf, Mi= chael (Nokia - DE) Sent: woensdag 18 mei 2016 19:34 To: Bob Briscoe; TCP Prague List Subject: Re: [tcpPrague] Draft L4S deliverables list Is there running code? Thx Michael From: tcpPrague [mailto:tcpprague-bounces@ietf.org] On Behalf Of Bob Brisco= e Sent: Wednesday, May 18, 2016 6:19 PM To: TCP Prague List Subject: [tcpPrague] Draft L4S deliverables list Folks, Here's the table of potential deliverables that I presented in Buenos Aires= . I've started to add volunteer's names. Pls continue... Each should probably be divided into implementation and drafting the spec, = but let's assume any volunteer will do both/either. Description Draft(s) Volunteers Target WG 1) L4S identifier draft-briscoe-tsvwg-ecn-l4s-id authors on draft tsvwg? 2) The DualQ AQM draft-briscoe-aqm-dualq-coupled authors on draft aqm? 3) Scalable Transport 3-1) Fall back to Reno/Cubic on loss Linux / tcpm 3-2) TCP ECN Feedback draft-ietf-tcpm-accurate-ecn authors on draft tcpm 3-4) Scaling TCP's Congestion Window for Small Round Trip Times Bob Briscoe, Marcelo Bagnulo Braun tcpm? 3-5) Reduce TCP / SCTCP / TCP Prague RTT-dependence tcpm? 3-6) Smooth ECN feedback over flow's RTT, not RTT hard-coded for DC tcpm? 3-7) Fall back to Reno/Cubic if classic ECN bottleneck detected tcpm? 3-8) Faster-than-additive increase Marcelo tcpm? 3-9) Less drastic exit from slow-start Marcelo, Bob tcpm? 4) "TCP Prague" (for the Internet) tcpm? 5) DCTCP bis (for data centres - may be the same as TCP Prague) draft-ietf-tcpm-dctcp (bis) tcpm? 6) "SCTP Prague" tcpm/tsvwg? 7) "RMCAT Prague" rmcat? Notes: A line can be drawn somewhere around 3-7) to indicate that everything above= is an essential safety feature (preventing starvation etc), while everythi= ng below (up to 3-9) is a performance improvement. 4,5,6) are essentially wrap-ups of the relevant elements from 3-1) to 3-9) = for each different transport 7) might require one draft for Nada, one for SCREAM, etc or it might be pos= sible to describe one simple delta for all RMCAT approaches. Whether we need all the bitty pieces 3-1) to 3-9) or whether we should go s= traight for the wrap-up solutions, is up for discussion. Bob -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --_000_BF6B00CC65FD2D45A326E74492B2C19FB7682CFBFR711WXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 <= /p>

>> It may not have been clear from what Koen said, = but DCTCP as-is{Note 1} already "works" alongside Classic TCP on = the public Internet with either of the AQMs Koen has implemented{Note 2}.

What I mea= nt was that DCTCP in Windows already implements topic 3-1) “Fall back= to Reno/Cubic on loss” below. It does not yet do the other topics in 3), but as Bob mentioned, we should define what is required for an L4S = TCP protocol to run save on the internet. Personally I think at least topic= s 1, 3-1, 3-2, 3-4, 3-5 and 3-7 are mandatory, and as long as they are not = resolved, DCTCP should be used in managed/contained environments only. I think 3-6 might be more an optimiza= tion (not sure though).

 = ;

Bob, 3-3 i= s missing, probably because you renamed that as 1, right?=

 = ;

Note that = in these managed environments DCTCP CAN already share automatically and fai= rly the throughput with classic TCPs if DualQ is used in the main bottlenecks. Also Windows DCTCP will work correctly (as Reno, so no L= 4S) in the legacy (drop-based) bottlenecks if they would appear, because it= implements 3-1). It won’t work if Classic ECN is enabled in these bo= ttlenecks, though as 3.2 and 3.7 are not resolved yet.

 = ;

Hope this = clarifies,

Koen.=

 = ;

 = ;

 = ;

 = ;

From:= Bob Briscoe [mailto= :research@bobbriscoe.net]
Sent: donderdag 19 mei 2016 12:55
To: De Schepper, Koen (Nokia - BE); Scharf, Michael (Nokia - DE)
Cc: TCP Prague List
Subject: Re: [tcpPrague] Draft L4S deliverables list

 

Michael, Koen, all,
Could people give a URL for any open source code (or failing that, binaries= ). Then I will add a link to this list:
https://riteproject.eu/dctth= /#code
In addition to Koen's list, you will see there a link to Mirja's TCP AccECN= code.

It may not have been clear from what Koen said, but DCTCP as-is{Note 1} alr= eady "works" alongside Classic TCP on the public Internet with ei= ther of the AQMs Koen has implemented{Note 2}.
However, the definition of "works"  is currently good enough= for performance and functional testing of DCTCP alongside Classic TCP, but= not sufficient for full safety in all circumstances.
Items 3-1) to 3-7) address safety in the various specific cases described.<= br>
The phrase "TCP Prague" is being used for a (currently hypothetic= al) TCP that implements sufficient of these features to be safe for use on = the public Internet.
One aim is for the IETF to determine which of these safety features are MUS= Ts, which are SHOULDs, etc.



Bob

{Note 1}: Tested with Linux and Windows versions of DCTCP
{Note 2}: With either Curvy RED or PI2 as the AQM for Classic traffic.

On 19/05/16 10:00, De Schepper, Koen (Nokia - BE) wr= ote:

For the AQ= M part (2) we have running code. Our latest DualQ-PI2 supports both ect(0) = and ect(1), doing classic ecn and L4S ecn respectively (covering topic 1 from the network). For 3.1, MS Windows has running code and we tes= ted that it is responding correctly to drop (we didn’t test FreeBSD).= Maybe others have more implementations?

 

Regards,

Koen.

 

 

 

Is there r= unning code?

 

Thx=

 

Michael

 

 

 

= Folks,

Here's the table of potential deliverables that I presented in Buenos Aires= . I've started to add volunteer's names.
Pls continue...

Each should probably be divided into implementation and drafting the spec, = but let's assume any volunteer will do both/either.

Description

Draft(s)

Volunteers

Target WG

1)

L4S identifier

draft-briscoe-tsvwg-ecn-l4s-id

authors on draft

tsvwg?

2)

The DualQ AQM

draft-briscoe-aqm-dualq-coupled

authors on draft

aqm?

3)

Scalable Transport

3-1)

Fall back to Reno/Cubic on loss

Linux / tcpm

3-2)

TCP ECN Feedback

draft-ietf-tcpm-accurate-ecn

authors on draft

tcpm

3-4)

Scaling TCP's Congestion Window for Small Round Trip= Times

Bob Briscoe, Marcelo Bagnulo Braun

tcpm?

3-5)

Reduce TCP / SCTCP / TCP Prague RTT-dependence<= /o:p>

tcpm?

3-6)

Smooth ECN feedback over flow's RTT, not RTT hard-co= ded for DC

tcpm?

3-7)

Fall back to Reno/Cubic if classic ECN bottleneck de= tected

tcpm?

3-8)

Faster-than-additive increase

Marcelo

tcpm?

3-9)

Less drastic exit from slow-start

Marcelo, Bob

tcpm?

4)

“TCP Prague” (for the Internet)

tcpm?

5)

DCTCP bis (for data centres - may be the same as TCP= Prague)

draft-ietf-tcpm-dctcp (bis)

tcpm?

6)

"SCTP Prague"

tcpm/tsvwg?

7)

“RMCAT Prague”

rmcat?

=
Notes:
A line can be drawn somewhere around 3-7) to indicate that everything a= bove is an essential safety feature (preventing starvation etc), while ever= ything below (up to 3-9) is a performance improvement.

4,5,6) are essentially wrap-ups of the relevant elements from 3-1) to 3-9) = for each different transport
7) might require one draft for Nada, one for SCREAM, etc or it might be pos= sible to describe one simple delta for all RMCAT approaches.

Whether we need all the bitty pieces 3-1) to 3-9) or whether we should go s= traight for the wrap-up solutions, is up for discussion.


Bob
   
     

-- 
_________________________________________________=
_______________
Bob Briscoe      &n=
bsp;            =
;            http://bobbriscoe.net/




-- 
________________________________________________________________<=
/o:p>
Bob Briscoe          =
;            &n=
bsp;        http://bobbriscoe.net/
--_000_BF6B00CC65FD2D45A326E74492B2C19FB7682CFBFR711WXCHMBA05z_-- From nobody Thu May 19 09:48:40 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC4312DA9F for ; Thu, 19 May 2016 09:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.026 X-Spam-Level: X-Spam-Status: No, score=-4.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426] 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 jNY9AApqva-l for ; Thu, 19 May 2016 09:48:36 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id C670212DA9A for ; Thu, 19 May 2016 09:48:34 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 56A28C9419; Thu, 19 May 2016 12:48:32 -0400 (EDT) Date: Thu, 19 May 2016 12:48:32 -0400 From: John Leslie To: Mirja K??hlewind Message-ID: <20160519164832.GB43983@verdi> References: <573C564E.1090201@bobbriscoe.net> <20160518170612.GA56178@verdi> <573DA385.8020703@bobbriscoe.net> <573DE5A9.70808@tik.ee.ethz.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <573DE5A9.70808@tik.ee.ethz.ch> User-Agent: Mutt/1.4.1i Archived-At: Cc: Bob Briscoe , TCP Prague List Subject: Re: [tcpPrague] Volunteers pls: L4S non-WG-forming BoF proposal cut-off approaching X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 16:48:38 -0000 Mirja K??hlewind wrote: > > You don't need a charter for a non-wg-forming BoF (which anyway wouldn't > make sense). However, you should have a description of the BoF (which > clearly lays out the goals of the BoF/discussion that is expected at the > BoF) to provide the needed information to request a BoF, see > > https://www.ietf.org/wg/bof-procedures.html > > I can also recommend to add your BoF information to the BoF wiki page: > > https://tools.ietf.org/bof/trac/ > > Template is given here: > > https://tools.ietf.org/bof/trac/wiki/BofExample > > Regarding any charter changes in other groups: these have the be discussed > and decided in the respective group. I don't think it's helpful to come up > with any text now, or even discuss this text during the BoF. I entirely agree with Mirja (though I don't warrantee the rest of the IESG does). I think it's worth adding what Mirja posted to the AQM list: ] ] AQM will have a recharter discussion at the next meeting which might lead to ] rechartering or closure. If the wg will continue, moving this doc forward ] might be one of their work items. Otherwise there are currently no plans. ] Even though there are implementations of PIE in the wild, the working did ] not have consensus to publish this doc as ST now, as these implementation ] are currently mostly used in home devices and not the Internet itself. So... if we imagine dual-queue work being carried out in AQM, we really ought to reach agreement with the current AQM chairs, and be prepared to help them with a rechartering proposal. If we wish to ensure our BoF comes before, or after, the AQM rechartering discussion, we need to beg Mirja to ensure that ordering, since such ordering is not part of the standard BoF-scheduling process, and swaps tend to happen as the process proceeds. OTOH, we could discuss that work in our BoF, stating that we'd be happy to see it become part of an AQM rechartering... IMHO, it would be more ordinary to discuss chartering such work within dual-queue (and be prepared to ask that it be part of our charter; again stating we're happy to see the work take place in AQM). -- John Leslie From nobody Thu May 19 09:57:50 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0A012DADB for ; Thu, 19 May 2016 09:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 fNkJ-r39RqAV for ; Thu, 19 May 2016 09:57:45 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F184812DAD6 for ; Thu, 19 May 2016 09:57:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 9F30BD930D; Thu, 19 May 2016 18:57:42 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ffIT4Nk72EkY; Thu, 19 May 2016 18:57:42 +0200 (MEST) Received: from [10.2.114.31] (public-docking-etx-0541.ethz.ch [10.2.114.31]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 64911D930C; Thu, 19 May 2016 18:57:42 +0200 (MEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <20160519164832.GB43983@verdi> Date: Thu, 19 May 2016 18:57:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4EDE6C3B-6D08-4718-8427-280E3AE0A41D@tik.ee.ethz.ch> References: <573C564E.1090201@bobbriscoe.net> <20160518170612.GA56178@verdi> <573DA385.8020703@bobbriscoe.net> <573DE5A9.70808@tik.ee.ethz.ch> <20160519164832.GB43983@verdi> To: John Leslie X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Bob Briscoe , TCP Prague List Subject: Re: [tcpPrague] Volunteers pls: L4S non-WG-forming BoF proposal cut-off approaching X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 16:57:49 -0000 Hi John, hi all, As far as I know, dual-q has been presented at an aqm meeting and in any = case the dual-q draft is an aqm draft (draft-briscoe-aqm-dualq-coupled). = So for sure the aqm wg is aware that this draft exists and I would = assume that this draft will be part of the re-charter discussion. = However, even if the group is interested in this work, it could still be = possible that it is not worth having a whole wg basically for just one = document (not saying that will be the case). However, even in this case = this work could also be continued by other groups in transport.=20 While knowing about the recharter effort of aqm is for sure good input = for the discussion in this potentially BoF, I think we can keep those = two efforts separate. Mirja > Am 19.05.2016 um 18:48 schrieb John Leslie : >=20 > Mirja K??hlewind wrote: >>=20 >> You don't need a charter for a non-wg-forming BoF (which anyway = wouldn't=20 >> make sense). However, you should have a description of the BoF (which=20= >> clearly lays out the goals of the BoF/discussion that is expected at = the=20 >> BoF) to provide the needed information to request a BoF, see >>=20 >> https://www.ietf.org/wg/bof-procedures.html >>=20 >> I can also recommend to add your BoF information to the BoF wiki = page: >>=20 >> https://tools.ietf.org/bof/trac/ >>=20 >> Template is given here: >>=20 >> https://tools.ietf.org/bof/trac/wiki/BofExample >>=20 >> Regarding any charter changes in other groups: these have the be = discussed=20 >> and decided in the respective group. I don't think it's helpful to = come up=20 >> with any text now, or even discuss this text during the BoF. >=20 > I entirely agree with Mirja (though I don't warrantee the rest of = the IESG > does). >=20 > I think it's worth adding what Mirja posted to the AQM list: > ]=20 > ] AQM will have a recharter discussion at the next meeting which might = lead to > ] rechartering or closure. If the wg will continue, moving this doc = forward > ] might be one of their work items. Otherwise there are currently no = plans. > ] Even though there are implementations of PIE in the wild, the = working did > ] not have consensus to publish this doc as ST now, as these = implementation=20 > ] are currently mostly used in home devices and not the Internet = itself. >=20 > So... if we imagine dual-queue work being carried out in AQM, we = really > ought to reach agreement with the current AQM chairs, and be prepared = to help > them with a rechartering proposal. >=20 > If we wish to ensure our BoF comes before, or after, the AQM = rechartering > discussion, we need to beg Mirja to ensure that ordering, since such = ordering > is not part of the standard BoF-scheduling process, and swaps tend to = happen > as the process proceeds. >=20 > OTOH, we could discuss that work in our BoF, stating that we'd be = happy to > see it become part of an AQM rechartering... >=20 > IMHO, it would be more ordinary to discuss chartering such work = within > dual-queue (and be prepared to ask that it be part of our charter; = again > stating we're happy to see the work take place in AQM). >=20 > -- > John Leslie >=20 > _______________________________________________ > tcpPrague mailing list > tcpPrague@ietf.org > https://www.ietf.org/mailman/listinfo/tcpprague From nobody Thu May 19 10:55:10 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8416612DB67 for ; Thu, 19 May 2016 10:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 yILrMxz24lTk for ; Thu, 19 May 2016 10:55:06 -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 06CA012DB66 for ; Thu, 19 May 2016 10:55:06 -0700 (PDT) Received: from dhcp-207-151.erg.abdn.ac.uk (unknown [IPv6:2001:630:241:207:9574:ce78:c10b:25bb]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 1E66C1B00050; Thu, 19 May 2016 19:07:24 +0100 (BST) References: <573C564E.1090201@bobbriscoe.net> <20160518170612.GA56178@verdi> <573DA385.8020703@bobbriscoe.net> <573DE5A9.70808@tik.ee.ethz.ch> <20160519164832.GB43983@verdi> <4EDE6C3B-6D08-4718-8427-280E3AE0A41D@tik.ee.ethz.ch> To: =?UTF-8?Q?Mirja_K=c3=bchlewind?= , John Leslie From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. Message-ID: <573DFDF8.2000609@erg.abdn.ac.uk> Date: Thu, 19 May 2016 18:55:04 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <4EDE6C3B-6D08-4718-8427-280E3AE0A41D@tik.ee.ethz.ch> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Bob Briscoe , TCP Prague List Subject: Re: [tcpPrague] Volunteers pls: L4S non-WG-forming BoF proposal cut-off approaching X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 17:55:08 -0000 Juts in case anyone is unfamiliar, I'd add that area working groups (in this TSVWG) tend to pick-up work that the AD assigns them, as well as their core work items. So, I'd encourage people to work out what they want to do and why this is needed, who will implement what is proposed, etc - I'm sure the work can be found an appropriate home if the IETF decides to proceed with this:-). Gorry On 19/05/2016 17:57, Mirja Khlewind wrote: > Hi John, hi all, > > As far as I know, dual-q has been presented at an aqm meeting and in any case the dual-q draft is an aqm draft (draft-briscoe-aqm-dualq-coupled). So for sure the aqm wg is aware that this draft exists and I would assume that this draft will be part of the re-charter discussion. However, even if the group is interested in this work, it could still be possible that it is not worth having a whole wg basically for just one document (not saying that will be the case). However, even in this case this work could also be continued by other groups in transport. > > While knowing about the recharter effort of aqm is for sure good input for the discussion in this potentially BoF, I think we can keep those two efforts separate. > > Mirja > > > >> Am 19.05.2016 um 18:48 schrieb John Leslie : >> >> Mirja K??hlewind wrote: >>> >>> You don't need a charter for a non-wg-forming BoF (which anyway wouldn't >>> make sense). However, you should have a description of the BoF (which >>> clearly lays out the goals of the BoF/discussion that is expected at the >>> BoF) to provide the needed information to request a BoF, see >>> >>> https://www.ietf.org/wg/bof-procedures.html >>> >>> I can also recommend to add your BoF information to the BoF wiki page: >>> >>> https://tools.ietf.org/bof/trac/ >>> >>> Template is given here: >>> >>> https://tools.ietf.org/bof/trac/wiki/BofExample >>> >>> Regarding any charter changes in other groups: these have the be discussed >>> and decided in the respective group. I don't think it's helpful to come up >>> with any text now, or even discuss this text during the BoF. >> >> I entirely agree with Mirja (though I don't warrantee the rest of the IESG >> does). >> >> I think it's worth adding what Mirja posted to the AQM list: >> ] >> ] AQM will have a recharter discussion at the next meeting which might lead to >> ] rechartering or closure. If the wg will continue, moving this doc forward >> ] might be one of their work items. Otherwise there are currently no plans. >> ] Even though there are implementations of PIE in the wild, the working did >> ] not have consensus to publish this doc as ST now, as these implementation >> ] are currently mostly used in home devices and not the Internet itself. >> >> So... if we imagine dual-queue work being carried out in AQM, we really >> ought to reach agreement with the current AQM chairs, and be prepared to help >> them with a rechartering proposal. >> >> If we wish to ensure our BoF comes before, or after, the AQM rechartering >> discussion, we need to beg Mirja to ensure that ordering, since such ordering >> is not part of the standard BoF-scheduling process, and swaps tend to happen >> as the process proceeds. >> >> OTOH, we could discuss that work in our BoF, stating that we'd be happy to >> see it become part of an AQM rechartering... >> >> IMHO, it would be more ordinary to discuss chartering such work within >> dual-queue (and be prepared to ask that it be part of our charter; again >> stating we're happy to see the work take place in AQM). >> >> -- >> John Leslie >> >> _______________________________________________ >> tcpPrague mailing list >> tcpPrague@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpprague > > _______________________________________________ > tcpPrague mailing list > tcpPrague@ietf.org > https://www.ietf.org/mailman/listinfo/tcpprague > From nobody Thu May 19 11:33:19 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 132B512DBB5; Thu, 19 May 2016 11:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 r0v5msBloBe8; Thu, 19 May 2016 11:33:06 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 A89A212DB99; Thu, 19 May 2016 11:29:40 -0700 (PDT) Received: from 173.7.199.146.dyn.plus.net ([146.199.7.173]:39946 helo=[192.168.0.10]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1b3ShW-0005G6-JJ; Thu, 19 May 2016 19:29:38 +0100 To: tsv-area IETF list , AQM IETF list , tcpm IETF list , tsvwg IETF list , "rmcat@ietf.org" From: Bob Briscoe Message-ID: <573E0611.5070803@bobbriscoe.net> Date: Thu, 19 May 2016 19:29:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------070606010507000205050305" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Cc: TCP Prague List Subject: [tcpPrague] L4S/DualQ BoF-forming on tcpprague list: pls air your concerns X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 18:33:11 -0000 This is a multi-part message in MIME format. --------------070606010507000205050305 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Multiple IETF Transport mailing lists. This is to announce that discussions are proceeding on the tcpprague@ietf.org list [see archive ] about organising a BoF on Low Latency Low Loss Scalable throughput (L4S) service, for the IETF-96 Berlin timeframe. The proposed L4S BoF will be about the full implications of L4S - on ECN, SCTP, RMCAT, AQM, etc. Despite the name of the mailing list, it is not just about so-called "TCP Prague" and its implications solely on TCP. If you reply to this announcement, please cut all the mailing lists from the distr except tcpprague. Anyone who is sceptical of the L4S approach, or its safety for the public Internet, please air your concerns. Ideally now on the tcpprague list, but certainly at or preferably before the proposed BoF in Berlin. If you prefer to air your concerns on your favourite WG mailing list, pls at least ensure the tcpprague list is aware. You may know L4S as the DualQ Coupled AQM. Background info on L4S including I-Ds, code, videos, etc. can be found here: https://riteproject.eu/dctth/ Cheers Bob > > -------- Forwarded Message -------- > Subject: Volunteers pls: L4S non-WG-forming BoF proposal cut-off > approaching > Date: Wed, 18 May 2016 12:47:26 +0100 > From: Bob Briscoe > To: TCP Prague List > > > > Folks, > > At the Low Latency, Low Loss Scalable throughput (L4S) Bar Bof in > Buenos Aires, there was support for a BoF about L4S, In the IETF-96 > (Berlin) time-frame. > It was decided to initially use this ML, even tho the scope of L4S is > wider than TCP Prague. > Consensus was to aim for a non-WG-forming BoF, to demonstrate > willingness to work on the pieces in existing IETF WGs, and to > co-ordinate approaches to each WG. > > The cut-off is now 2.5 weeks away. > *2016-06-03 (Friday):* Cut-off date for BOF proposal requests to Area > Directors at UTC 23:59. > > To organise a successful BoF (referring to rfc5434 > ), we need volunteers for the > following tasks: > #/ Draft a statement of problem & scope > #/ List planned deliverables (incl. implementation, spec drafting), > milestones and target WG (also identify any critical interdependencies) > #/ Identify and draft any necessary changes to WG charters, to cover > the above deliverables > #/ Discuss with relevant WG chairs and ADs [see background below] > #/ Identify volunteers (pref before the BoF) planning to work on each > deliverable > > Some people have already volunteered in general to help with arranging > the BoF, but we now need to get specific. > > Let's get volunteers for the above priority tasks first, but for > completeness I'll also list the formalities we have to do: > #/ Decide on name of BoF (and mailing list) > #/ BoF facilitators - chairs, scribes, etc > #/ Draft the BoF agenda, incl. time constraints > #/ Decide on the BoF questions > #/ Estimate attendance, list conflicts, decide duration > #/ Submit a formal request for the BoF via > http://www.ietf.org/instructions/MTG-SLOTS.html and > http://www.ietf.org/ietf/1bof-procedures.txt > > I'll start off co-ordinating and chasing all the above, but contact me > if you would like to take on the co-ordinating task. > > *Background work so far** > * > The idea of this BoF has been floated with WG chairs and ADs for some > time now (since Nov'15 in Yokohama), except AFAIK, we haven't talked > with the RMCAT chairs. > Also we have already done considerable work on defining the problem > while writing various drafts and papers about L4S. > > But, that was just a small group of co-authors (me, Koen, Inton, > Olga). There's still a lot to do to build wider consensus. > We can go ahead with a BoF scheduling request even if disagreements on > scope/problem remain. > But before the BoF itself, we need to have any such disagreements > ironed out. > > At the Buenos Aires Bar Bof, we put up a todo list of pieces that will > need to be worked on: > See http://www.bobbriscoe.net/presents/1604ietf/1604-l4s-bar-bof.pdf > particularly slides 9 & 10 > and the target WGs for each were: > * TSVWG (the L4S identifier) > * AQM (the AQM - the name gives the clue ;) > * TCPM (the DCTCP-like congestion control, covering SCTP) > * RMCAT (L4S variants of real-time congestion controls, or at least > standardise existing controls using the identifier) > > I believe, formally, each WG has to decide to charter additional work > on its own ML. > > [Since then, Ingemar has pointed out on this list that we also need to > get AQM & ECN-marking in radio networks, and that will require working > with/through other SDOs and/or developer groups that deal with the MAC > layer . > V. important, but let's push that to a separate thread.] > > Many of the pieces have their own rationale, independent of L4S. The > idea of the BoF is to draw the bigger picture that motivates the work. > That doesn't preclude incremental work on the pieces for those who are > not motivated by a big picture. > > Cheers > > > > Bob -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------070606010507000205050305 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Multiple IETF Transport mailing lists.

This is to announce that discussions are proceeding on the tcpprague@ietf.org list [see archive] about organising a BoF on Low Latency Low Loss Scalable throughput (L4S) service, for the IETF-96 Berlin timeframe.
The proposed L4S BoF will be about the full implications of L4S - on ECN, SCTP, RMCAT, AQM, etc. Despite the name of the mailing list, it is not just about so-called "TCP Prague" and its implications solely on TCP.

If you reply to this announcement, please cut all the mailing lists from the distr except tcpprague.

Anyone who is sceptical of the L4S approach, or its safety for the public Internet, please air your concerns. Ideally now on the tcpprague list, but certainly at or preferably before the proposed BoF in Berlin.
If you prefer to air your concerns on your favourite WG mailing list, pls at least ensure the tcpprague list is aware.

You may know L4S as the DualQ Coupled AQM. Background info on L4S including I-Ds, code, videos, etc. can be found here:
https://riteproject.eu/dctth/

Cheers




Bob


-------- Forwarded Message --------
Subject: Volunteers pls: L4S non-WG-forming BoF proposal cut-off approaching
Date: Wed, 18 May 2016 12:47:26 +0100
From: Bob Briscoe <ietf@bobbriscoe.net>
To: TCP Prague List <tcpPrague@ietf.org>


Folks,

At the Low Latency, Low Loss Scalable throughput (L4S) Bar Bof in Buenos Aires, there was support for a BoF about L4S, In the IETF-96 (Berlin) time-frame.
It was decided to initially use this ML, even tho the scope of L4S is wider than TCP Prague.
Consensus was to aim for a non-WG-forming BoF, to demonstrate willingness to work on the pieces in existing IETF WGs, and to co-ordinate approaches to each WG.

The cut-off is now 2.5 weeks away.
*2016-06-03 (Friday):* Cut-off date for BOF proposal requests to Area Directors at UTC 23:59.

To organise a successful BoF (referring to rfc5434), we need volunteers for the following tasks:
#/ Draft a statement of problem & scope
#/ List planned deliverables (incl. implementation, spec drafting), milestones and target WG (also identify any critical interdependencies)
#/ Identify and draft any necessary changes to WG charters, to cover the above deliverables
#/ Discuss with relevant WG chairs and ADs [see background below]
#/ Identify volunteers (pref before the BoF) planning to work on each deliverable

Some people have already volunteered in general to help with arranging the BoF, but we now need to get specific.

Let's get volunteers for the above priority tasks first, but for completeness I'll also list the formalities we have to do:
#/ Decide on name of BoF (and mailing list)
#/ BoF facilitators - chairs, scribes, etc
#/ Draft the BoF agenda, incl. time constraints
#/ Decide on the BoF questions
#/ Estimate attendance, list conflicts, decide duration
#/ Submit a formal request for the BoF via
     http://www.ietf.org/instructions/MTG-SLOTS.html and
     http://www.ietf.org/ietf/1bof-procedures.txt

I'll start off co-ordinating and chasing all the above, but contact me if you would like to take on the co-ordinating task.

Background work so far

The idea of this BoF has been floated with WG chairs and ADs for some time now (since Nov'15 in Yokohama), except AFAIK, we haven't talked with the RMCAT chairs.
Also we have already done considerable work on defining the problem while writing various drafts and papers about L4S.

But, that was just a small group of co-authors (me, Koen, Inton, Olga). There's still a lot to do to build wider consensus.
We can go ahead with a BoF scheduling request even if disagreements on scope/problem remain.
But before the BoF itself, we need to have any such disagreements ironed out.

At the Buenos Aires Bar Bof, we put up a todo list of pieces that will need to be worked on:
See http://www.bobbriscoe.net/presents/1604ietf/1604-l4s-bar-bof.pdf particularly slides 9 & 10
and the target WGs for each were:
* TSVWG (the L4S identifier)
* AQM (the AQM - the name gives the clue ;)
* TCPM (the DCTCP-like congestion control, covering SCTP)
* RMCAT (L4S variants of real-time congestion controls, or at least standardise existing controls using the identifier)

I believe, formally, each WG has to decide to charter additional work on its own ML.

[Since then, Ingemar has pointed out on this list that we also need to get AQM & ECN-marking in radio networks, and that will require working with/through other SDOs and/or developer groups that deal with the MAC layer .
V. important, but let's push that to a separate thread.]

Many of the pieces have their own rationale, independent of L4S. The idea of the BoF is to draw the bigger picture that motivates the work.
That doesn't preclude incremental work on the pieces for those who are not motivated by a big picture.

Cheers



Bob




-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------070606010507000205050305-- From nobody Thu May 19 12:03:32 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D20D12DB9A for ; Thu, 19 May 2016 12:03:31 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 Qq6FtaZniiyt for ; Thu, 19 May 2016 12:03:29 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 97BB812DBC0 for ; Thu, 19 May 2016 12:03:29 -0700 (PDT) Received: from 173.7.199.146.dyn.plus.net ([146.199.7.173]:39977 helo=[192.168.0.10]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1b3TEF-0008Ch-Bd; Thu, 19 May 2016 20:03:27 +0100 To: "Scharf, Michael (Nokia - DE)" , John Leslie References: <573C564E.1090201@bobbriscoe.net> <20160518170612.GA56178@verdi> <573DA385.8020703@bobbriscoe.net> <655C07320163294895BBADA28372AF5D4885C7A9@FR712WXCHMBA15.zeu.alcatel-lucent.com> From: Bob Briscoe Message-ID: <573E0DFD.1060702@bobbriscoe.net> Date: Thu, 19 May 2016 20:03:25 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <655C07320163294895BBADA28372AF5D4885C7A9@FR712WXCHMBA15.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Cc: TCP Prague List Subject: Re: [tcpPrague] Volunteers pls: L4S non-WG-forming BoF proposal cut-off approaching X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 19:03:31 -0000 Michael, Over the coming days / weeks, we will try to expose the vast numbers of experiments that have been done. And on real broadband equipment, in realistic traffic settings, etc. (the realism being for you to judge, not me) Regarding running code, often at the time when a 'typical' BoF is held, there is some example or initial code, but not code for every proposed milestone. We are much further ahead than just initial code. But most of the "TCP Prague" safety aspects are still only a list of desires, not code. To ensure I understand your concern,... I assume even tho your email is as an individual, you are focusing on those aspects relevant to tcpm, which are all those safety points - mostly not implemented. Or are you questioning the adequacy of the AQM code, the DCTCP code etc? The problem here is that, if we were proposing a new WG, it would be normal to create a charter with a list of milestones, many of which would not have even been thought about in detail, let alone implemented. Milestones might be requirements documents, not protocol specs at that stage. Nonetheless, because we are proposing to work across existing WGs, I accept we have to adapt to the norms of each WG. Nonetheless, even in TCPM, it is possible to start some work with a requirements doc, rather than a fully-tested implementation. Also, part of this discussion is about whether WG norms need to be stretched to accommodate L4S work. Or whether a new WG is needed. For instance, when we discussed how to take L4S forward with the ADs (and a few very relevant WG chairs who happened to be in the Transport AD Office hours at the time), there was v strong consensus that we should avoid going off into an L4S huddle in a separate WG. And one of the ADs said we might have to consider widening the definition of "minor extensions" in TCPM's charter as a consequence. Bob On 19/05/16 13:54, Scharf, Michael (Nokia - DE) wrote: >> The biggest question-mark is over tcpm. One of the reasons for showing the full list of possible work (even tho some isn't even started) is to: >> * expose the potential load on tcpm {Note 1} >> * enable discussion on whether the phrase "minor" in tcpm's charter would need to be nuanced to encompass minor changes that have major effects >> {Note 1} Some of the deliverables would be brought to tcpm anyway, because they are important for all TCP-derived congestion controls, not just "TCP Prague". >> For instance, the following two RTT-related items are particularly important for L4S/"TCP Prague", but they are also important updates to the base TCP cc [RFC5681] too. >> 3-4) Scaling TCP's Congestion Window for Small Round Trip Times >> 3-5) Reduce TCP / SCTCP / TCP Prague RTT-dependence > Before speculating too much about the TCPM charter, I believe that running code and (realistic) experimentation would be an important starting point. > > Michael (as individual contributor) > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Thu May 19 12:12:48 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2A212DBD1 for ; Thu, 19 May 2016 12:12:47 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 cLq7AC5ftuD2 for ; Thu, 19 May 2016 12:12:45 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 7D3DA12DBBC for ; Thu, 19 May 2016 12:12:45 -0700 (PDT) Received: from 173.7.199.146.dyn.plus.net ([146.199.7.173]:39985 helo=[192.168.0.10]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1b3TND-0000Y1-J8; Thu, 19 May 2016 20:12:43 +0100 To: =?UTF-8?Q?Mirja_K=c3=bchlewind?= , John Leslie References: <573C564E.1090201@bobbriscoe.net> <20160518170612.GA56178@verdi> <573DA385.8020703@bobbriscoe.net> <573DE5A9.70808@tik.ee.ethz.ch> <20160519164832.GB43983@verdi> <4EDE6C3B-6D08-4718-8427-280E3AE0A41D@tik.ee.ethz.ch> <573DFDF8.2000609@erg.abdn.ac.uk> From: Bob Briscoe Message-ID: <573E102A.4040804@bobbriscoe.net> Date: Thu, 19 May 2016 20:12:42 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <573DFDF8.2000609@erg.abdn.ac.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Cc: gorry@erg.abdn.ac.uk, TCP Prague List Subject: Re: [tcpPrague] Volunteers pls: L4S non-WG-forming BoF proposal cut-off approaching X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 19:12:47 -0000 Mirja, John, [and thanks for pointing out the role of the area WG, Gorry] Going back to your point about scheduling the order of re-chartering discussion meetings in Berlin. We don't have to wait for the f2f meeting to discuss re-chartering aqm (or any of the WGs potentially affected by L4S work). We can start now on the relevant MLs, so the f2f mtgs become a coordination checkpoint for the discussions, like they should be. But in general, it might be useful to have the L4S BoF (if approved) early in the week, so that discussions specific to each WG can be held with the largest number of people aware of the wider context of the discussion. Bob On 19/05/16 18:55, Gorry Fairhurst wrote: > Juts in case anyone is unfamiliar, I'd add that area working groups > (in this TSVWG) tend to pick-up work that the AD assigns them, as well > as their core work items. > > So, I'd encourage people to work out what they want to do and why this > is needed, who will implement what is proposed, etc - I'm sure the > work can be found an appropriate home if the IETF decides to proceed > with this:-). > > Gorry > > On 19/05/2016 17:57, Mirja Kühlewind wrote: >> Hi John, hi all, >> >> As far as I know, dual-q has been presented at an aqm meeting and in >> any case the dual-q draft is an aqm draft >> (draft-briscoe-aqm-dualq-coupled). So for sure the aqm wg is aware >> that this draft exists and I would assume that this draft will be >> part of the re-charter discussion. However, even if the group is >> interested in this work, it could still be possible that it is not >> worth having a whole wg basically for just one document (not saying >> that will be the case). However, even in this case this work could >> also be continued by other groups in transport. >> >> While knowing about the recharter effort of aqm is for sure good >> input for the discussion in this potentially BoF, I think we can keep >> those two efforts separate. >> >> Mirja >> >> >> >>> Am 19.05.2016 um 18:48 schrieb John Leslie : >>> >>> Mirja K??hlewind wrote: >>>> >>>> You don't need a charter for a non-wg-forming BoF (which anyway >>>> wouldn't >>>> make sense). However, you should have a description of the BoF (which >>>> clearly lays out the goals of the BoF/discussion that is expected >>>> at the >>>> BoF) to provide the needed information to request a BoF, see >>>> >>>> https://www.ietf.org/wg/bof-procedures.html >>>> >>>> I can also recommend to add your BoF information to the BoF wiki page: >>>> >>>> https://tools.ietf.org/bof/trac/ >>>> >>>> Template is given here: >>>> >>>> https://tools.ietf.org/bof/trac/wiki/BofExample >>>> >>>> Regarding any charter changes in other groups: these have the be >>>> discussed >>>> and decided in the respective group. I don't think it's helpful to >>>> come up >>>> with any text now, or even discuss this text during the BoF. >>> >>> I entirely agree with Mirja (though I don't warrantee the rest of >>> the IESG >>> does). >>> >>> I think it's worth adding what Mirja posted to the AQM list: >>> ] >>> ] AQM will have a recharter discussion at the next meeting which >>> might lead to >>> ] rechartering or closure. If the wg will continue, moving this doc >>> forward >>> ] might be one of their work items. Otherwise there are currently no >>> plans. >>> ] Even though there are implementations of PIE in the wild, the >>> working did >>> ] not have consensus to publish this doc as ST now, as these >>> implementation >>> ] are currently mostly used in home devices and not the Internet >>> itself. >>> >>> So... if we imagine dual-queue work being carried out in AQM, we >>> really >>> ought to reach agreement with the current AQM chairs, and be >>> prepared to help >>> them with a rechartering proposal. >>> >>> If we wish to ensure our BoF comes before, or after, the AQM >>> rechartering >>> discussion, we need to beg Mirja to ensure that ordering, since such >>> ordering >>> is not part of the standard BoF-scheduling process, and swaps tend >>> to happen >>> as the process proceeds. >>> >>> OTOH, we could discuss that work in our BoF, stating that we'd be >>> happy to >>> see it become part of an AQM rechartering... >>> >>> IMHO, it would be more ordinary to discuss chartering such work >>> within >>> dual-queue (and be prepared to ask that it be part of our charter; >>> again >>> stating we're happy to see the work take place in AQM). >>> >>> -- >>> John Leslie >>> >>> _______________________________________________ >>> tcpPrague mailing list >>> tcpPrague@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpprague >> >> _______________________________________________ >> tcpPrague mailing list >> tcpPrague@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpprague >> > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Sat May 21 16:31:56 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6BC412D584 for ; Sat, 21 May 2016 16:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.026 X-Spam-Level: X-Spam-Status: No, score=-4.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426] 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 CDiDIYB6Z6jI for ; Sat, 21 May 2016 16:31:53 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 744A712D539 for ; Sat, 21 May 2016 16:31:53 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 9492DC9419; Sat, 21 May 2016 19:31:47 -0400 (EDT) Date: Sat, 21 May 2016 19:31:47 -0400 From: John Leslie To: Bob Briscoe Message-ID: <20160521233147.GA6947@verdi> References: <573C564E.1090201@bobbriscoe.net> <20160518170612.GA56178@verdi> <573DA385.8020703@bobbriscoe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <573DA385.8020703@bobbriscoe.net> User-Agent: Mutt/1.4.1i Archived-At: Cc: TCP Prague List Subject: Re: [tcpPrague] Volunteers pls: L4S non-WG-forming BoF proposal cut-off approaching X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2016 23:31:55 -0000 It's time for me to reply to the list here... Bob Briscoe wrote: > On 18/05/16 18:06, John Leslie wrote: >> Bob Briscoe wrote: >> >>> At the Low Latency, Low Loss Scalable throughput (L4S) Bar Bof in Buenos >>> Aires, there was support for a BoF about L4S, In the IETF-96 (Berlin) >>> time-frame. >>> It was decided to initially use this ML, even tho the scope of L4S is >>> wider than TCP Prague. >>> Consensus was to aim for a non-WG-forming BoF, to demonstrate >>> willingness to work on the pieces in existing IETF WGs, and to >>> co-ordinate approaches to each WG. >> I'm not sure we're all convinced this work _can_ be done by the >> existing WGs -- if it can, I'm all for that. Actually, _I'm_ not convinced that it'll work for us to spread the work around. :^( > I don't think it is such a problem for AQM and tsvwg. I'd be more convinced if I heard this from the AQM and TSVWG chairs. > The biggest question-mark is over tcpm. One of the reasons for showing > the full list of possible work (even tho some isn't even started) is to: > * expose the potential load on tcpm {Note 1} > * enable discussion on whether the phrase "minor" in tcpm's charter > would need to be nuanced to encompass minor changes that have major > effects IMHO, TCPM has been the place for ongoing work on TCP which isn't expected to raise anybody's hackles. Once anybody sees it as "major", a different process is invoked. I don't think we'll get away with saying the changes are "minor" if they require "fundamental" changes to TCP. > {Note 1} Some of the deliverables would be brought to tcpm anyway, > because they are important for all TCP-derived congestion controls, not > just "TCP Prague". > For instance, the following two RTT-related items are particularly > important for L4S/"TCP Prague", but they are also important updates to > the base TCP cc [RFC5681] too. > 3-4) Scaling TCP's Congestion Window for Small Round Trip Times > 3-5) Reduce TCP / SCTCP / TCP Prague RTT-dependence This is almost off-topic. :^( The "small round-trip times" issue is pretty fundamental: TCP _doesn't_ reduce its congestion window below 2 (packets); so with enough classic-TCP senders, no AQM can possibly hold latency low. Bob has proposed a change; but it's a change to _every_ classic TCP sender. Myself, I'd rather not worry about this just yet... RTT-dependence is an inseparable part of TCP-as-we-know-it. I'd _much_ rather not tilt at that windmill quite yet... > Normally, a WG-forming BOF proposes a charter. Yes, but that's not essential. See https://www.ietf.org/wg/bof-procedures.html A Description and Agenda are required. A charter _may_ be discussed, but it's normal to leave this to a second BoF or hash out some details and propose it to the community. The _main_ purpose of a BoF is to have a "brief" discussion to see whether there's enough interest to justify forming a WG. The IESG is becoming a bit nervous about (formal) BoFs that don't propose to form a WG. Informal BoFs are fine; but formal scheduled BoFs are designed for deciding whether to form a WG. > Is it appropriate for a BoF to propose a co-ordinated set of charter > deltas across multiple existing WGs? No. > Or would it be more normal/polite/effective to propose/agree those > changes in each WG? It is considered _necessary_ to discuss those in each WG. (It's OK to ask the WGCs involved for advice about how to discuss that.) > Or would the best approach be to propose the changes in the BoF, then > discuss/agree each change in each WG as well? The IESG certainly wouldn't recommend that. It's entirely too easy for discussion to get hung up on details. > (I already understand that the IESG formally approves any charter > changes.) Formally, yes; in fact, these are not discussed much on IESG telechats. > Cheers I mean to post some advice on a better way to proceed; but this seems enough for one email... -- John Leslie From nobody Sat May 21 16:55:46 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A5E12D566 for ; Sat, 21 May 2016 16:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.026 X-Spam-Level: X-Spam-Status: No, score=-4.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426] 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 ZtIr3n0Zc7qw for ; Sat, 21 May 2016 16:55:43 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 51DDD12D1D3 for ; Sat, 21 May 2016 16:55:43 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id D9F2FC9413; Sat, 21 May 2016 19:55:39 -0400 (EDT) Date: Sat, 21 May 2016 19:55:39 -0400 From: John Leslie To: Mirja K??hlewind Message-ID: <20160521235539.GB6947@verdi> References: <573C564E.1090201@bobbriscoe.net> <20160518170612.GA56178@verdi> <573DA385.8020703@bobbriscoe.net> <573DE5A9.70808@tik.ee.ethz.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <573DE5A9.70808@tik.ee.ethz.ch> User-Agent: Mutt/1.4.1i Archived-At: Cc: Bob Briscoe , TCP Prague List Subject: Re: [tcpPrague] Volunteers pls: L4S non-WG-forming BoF proposal cut-off approaching X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2016 23:55:45 -0000 (not that I in any way disagree; this seems like the best starting point for what I believe we should discuss:) Mirja K??hlewind wrote: > > You don't need a charter for a non-wg-forming BoF (which anyway wouldn't > make sense). However, you should have a description of the BoF (which > clearly lays out the goals of the BoF/discussion that is expected at the > BoF) It seems to me that we have two really-fundamental items: 1) How to relax the requirement that ECN-marking results in the "same" reaction as a drop; and 2) How to deprecate ECN-nonce, which encourages seemingly-random switching between ECT-0 and ECT-1. I don't believe it appropriate to try to change either of these in an Experimental status document. (And I think we'll get in trouble if we try.) Thus, I'd like to see a first deliverable be a Proposed Standard laying out ground-rules for (quite possibly multiple) Experimental status documents. I know I've seen a fairly wide range of proposals differing in details from L4S (some of them very dependent upon variations in delay); and it's hard to believe that nobody will still want to push for their idea. I'd like to see a new WG chartered to oversee the appropriate experiments. This really doesn't fit any existing WG on Bob's list; and IMHO it's the easiest path to gain widespread support. (Or do any of you disagree that a lot of folks would like to _do_something_ about latency?) As for the particulars of L4S, I like it: but that doesn't mean that _everybody_ will like it. To tell truth, it's a bit hard to understand... The question of how to proceed with the L4S experiment remains open; and I would see no problem in evaluating it under the WG to be formed. If we want to put that in our charter, I won't object; but I really don't want to get hung-up on those details before we get authorization to respond differently to ECN marking and some assurance that we can treat ECT-0 and ECT-1 differently. If we go this path, we can spend the BoF justifying the efforts to free up ECT-0 and ECT-1 without having to argue details during the BoF. -- John Leslie From nobody Sun May 22 03:17:43 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D556E12D1E0 for ; Sun, 22 May 2016 03:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 Eha1GFdo4EFX for ; Sun, 22 May 2016 03:17:39 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (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 9BB7812B036 for ; Sun, 22 May 2016 03:17:39 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1b4QRz-0001aO-Hu; Sun, 22 May 2016 12:17:35 +0200 Received: from 3.134.189.109.customer.cdi.no ([109.189.134.3] helo=[192.168.0.103]) by mail-mx3.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1b4QRz-0001ns-3b; Sun, 22 May 2016 12:17:35 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Welzl In-Reply-To: <20160521233147.GA6947@verdi> Date: Sun, 22 May 2016 12:17:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9C86240F-3E2B-4534-9140-48D8286176A7@ifi.uio.no> References: <573C564E.1090201@bobbriscoe.net> <20160518170612.GA56178@verdi> <573DA385.8020703@bobbriscoe.net> <20160521233147.GA6947@verdi> To: John Leslie X-Mailer: Apple Mail (2.3124) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 3 sum msgs/h 1 total rcpts 41968 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 0835C99EAF10A523AD3B381A35658497BD975520 X-UiO-SPAM-Test: remote_host: 109.189.134.3 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1047 max/h 14 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Bob Briscoe , TCP Prague List Subject: Re: [tcpPrague] Volunteers pls: L4S non-WG-forming BoF proposal cut-off approaching X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2016 10:17:42 -0000 Hi all, Just one comment: (snip) >> {Note 1} Some of the deliverables would be brought to tcpm anyway,=20 >> because they are important for all TCP-derived congestion controls, = not=20 >> just "TCP Prague". >> For instance, the following two RTT-related items are particularly=20 >> important for L4S/"TCP Prague", but they are also important updates = to=20 >> the base TCP cc [RFC5681] too. >> 3-4) Scaling TCP's Congestion Window for Small Round Trip Times >> 3-5) Reduce TCP / SCTCP / TCP Prague RTT-dependence >=20 > This is almost off-topic. :^( >=20 > The "small round-trip times" issue is pretty fundamental: TCP = _doesn't_ > reduce its congestion window below 2 (packets); so with enough = classic-TCP > senders, no AQM can possibly hold latency low. Bob has proposed a = change; > but it's a change to _every_ classic TCP sender. Myself, I'd rather = not > worry about this just yet... >=20 > RTT-dependence is an inseparable part of TCP-as-we-know-it. I'd = _much_ > rather not tilt at that windmill quite yet=E2=80=A6 So here=E2=80=99s the +1. I can=E2=80=99t see how it helps this work if = we discuss all the possible problems of the world and how it can = possibly solve them. Opening many cans of various worms - wouldn=E2=80=99t it be better to = keep things more focused? Cheers, Michael From nobody Sun May 22 04:09:07 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F75012D10A for ; Sun, 22 May 2016 04:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 JR4HL-KP1UIc for ; Sun, 22 May 2016 04:09:03 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (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 1967B12B018 for ; Sun, 22 May 2016 04:09:03 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1b4RFj-0003u4-PS; Sun, 22 May 2016 13:08:59 +0200 Received: from 3.134.189.109.customer.cdi.no ([109.189.134.3] helo=[192.168.0.103]) by mail-mx3.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1b4RFj-00065W-5z; Sun, 22 May 2016 13:08:59 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Welzl In-Reply-To: <20160521235539.GB6947@verdi> Date: Sun, 22 May 2016 13:08:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <573C564E.1090201@bobbriscoe.net> <20160518170612.GA56178@verdi> <573DA385.8020703@bobbriscoe.net> <573DE5A9.70808@tik.ee.ethz.ch> <20160521235539.GB6947@verdi> To: John Leslie X-Mailer: Apple Mail (2.3124) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 7 msgs/h 1 sum rcpts/h 9 sum msgs/h 2 total rcpts 41976 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: BA13B2DDEBF10B8C2B822ECA6F7D2D9B97114AB7 X-UiO-SPAM-Test: UIO-GREYLIST remote_host: 109.189.134.3 spam_score: -49 maxlevel 80 minaction 1 bait 0 mail/h: 1 total 1049 max/h 14 blacklist 0 greylist 1 ratelimit 0 Archived-At: Cc: " Fairhurst" , grenville armitage , Bob Briscoe , Mirja K??hlewind , TCP Prague List , " Khademi" Subject: Re: [tcpPrague] Volunteers pls: L4S non-WG-forming BoF proposal cut-off approaching X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2016 11:09:05 -0000 [adding the co-authors of the ABE draft] All, My thoughts regarding the two items that John mentions below: To 1) =3D> the problematic statements from RFC3168 are on the third = slide here: https://www.ietf.org/proceedings/95/slides/slides-95-tsvwg-13.pdf (sorry for forgetting to use slide numbers!) They talk about =E2=80=9Cthe indication of congestion=E2=80=9D and "the = receipt by an ECN-Capable transport of a single CE packet=E2=80=9D. The receiver gets this signal, but the congestion reaction happens at = the sender - so these sentences assume the feedback mechanism described = in the same document. It seems strange to me to have to update these sentence (regarding how = congestion control mechanisms should react) for the purpose of L4S, = which relies on an entirely different feedback mechanism; reacting = exactly as if there would have been loss in response to an accurate ECN = signal is just completely weird. Rather, in the proposed update that we=E2=80=99re planning to do for the = sake of ABE (which assumes =E2=80=9Cnormal=E2=80=9D RFC3168-style = feedback), we should probably talk about the ECE mechanism "described in = this document=E2=80=9D or something like that - and the L4S work should = be able to (rightfully) assume that the reaction in response to accurate = ECN simply isn=E2=80=99t defined yet. To 2) =3D> Procedurally, I just wonder, is it really necessary to = =E2=80=9Cdeprecate=E2=80=9D (replace?) an Experimental RFC? As for the = technical side of it, we could just require the L4S work to discuss the = case of a lying receiver in the Security Considerations section - there = could be various possibilities for dealing with that, I=E2=80=99d = assume=E2=80=A6 (e.g. monitoring the feedback after giving an ECN = indication, in case of symmetric paths) - I think Bob had other = arguments; either way I don=E2=80=99t see a huge issue here. Cheers, Michael > On 22. mai 2016, at 01.55, John Leslie wrote: >=20 > (not that I in any way disagree; this seems like the best starting > point for what I believe we should discuss:) >=20 > Mirja K??hlewind wrote: >>=20 >> You don't need a charter for a non-wg-forming BoF (which anyway = wouldn't=20 >> make sense). However, you should have a description of the BoF (which=20= >> clearly lays out the goals of the BoF/discussion that is expected at = the=20 >> BoF) >=20 > It seems to me that we have two really-fundamental items: >=20 > 1) How to relax the requirement that ECN-marking results in the "same" > reaction as a drop; and >=20 > 2) How to deprecate ECN-nonce, which encourages seemingly-random = switching > between ECT-0 and ECT-1. >=20 > I don't believe it appropriate to try to change either of these in = an > Experimental status document. (And I think we'll get in trouble if we = try.) >=20 > Thus, I'd like to see a first deliverable be a Proposed Standard = laying > out ground-rules for (quite possibly multiple) Experimental status = documents. > I know I've seen a fairly wide range of proposals differing in details = from > L4S (some of them very dependent upon variations in delay); and it's = hard > to believe that nobody will still want to push for their idea. >=20 > I'd like to see a new WG chartered to oversee the appropriate = experiments. > This really doesn't fit any existing WG on Bob's list; and IMHO it's = the > easiest path to gain widespread support. (Or do any of you disagree = that > a lot of folks would like to _do_something_ about latency?) >=20 > As for the particulars of L4S, I like it: but that doesn't mean that > _everybody_ will like it. To tell truth, it's a bit hard to = understand... >=20 > The question of how to proceed with the L4S experiment remains open; > and I would see no problem in evaluating it under the WG to be formed. > If we want to put that in our charter, I won't object; but I really = don't > want to get hung-up on those details before we get authorization to > respond differently to ECN marking and some assurance that we can = treat > ECT-0 and ECT-1 differently. >=20 > If we go this path, we can spend the BoF justifying the efforts to > free up ECT-0 and ECT-1 without having to argue details during the = BoF. >=20 > -- > John Leslie >=20 > _______________________________________________ > tcpPrague mailing list > tcpPrague@ietf.org > https://www.ietf.org/mailman/listinfo/tcpprague From nobody Sun May 22 09:45:16 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7930212D148 for ; Sun, 22 May 2016 09:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 VkYh_N3Ko5Pt for ; Sun, 22 May 2016 09:45:13 -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 DA1F112D13D for ; Sun, 22 May 2016 09:45:11 -0700 (PDT) Received: from erg.abdn.ac.uk (galactica.erg.abdn.ac.uk [139.133.210.32]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 996D31B0025D; Sun, 22 May 2016 17:57:21 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by erg.abdn.ac.uk with HTTP; Sun, 22 May 2016 17:45:09 +0100 Message-ID: <824594fe27ca29beab42ee5dccd9a534.squirrel@erg.abdn.ac.uk> In-Reply-To: References: <573C564E.1090201@bobbriscoe.net> <20160518170612.GA56178@verdi> <573DA385.8020703@bobbriscoe.net> <573DE5A9.70808@tik.ee.ethz.ch> <20160521235539.GB6947@verdi> Date: Sun, 22 May 2016 17:45:09 +0100 From: gorry@erg.abdn.ac.uk To: "Michael Welzl" User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: gorry@erg.abdn.ac.uk, grenville armitage , Bob Briscoe , Mirja K??hlewind , TCP Prague List , naeemk@ifi.uio.no, John Leslie Subject: Re: [tcpPrague] Volunteers pls: L4S non-WG-forming BoF proposal cut-off approaching X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2016 16:45:15 -0000 See some comments below on these topics. > [adding the co-authors of the ABE draft] > > All, > > My thoughts regarding the two items that John mentions below: > > To 1) => the problematic statements from RFC3168 are on the third slide > here: > https://www.ietf.org/proceedings/95/slides/slides-95-tsvwg-13.pdf > (sorry for forgetting to use slide numbers!) > > They talk about “the indication of congestion” and "the receipt by an > ECN-Capable transport of a single CE packet”. > The receiver gets this signal, but the congestion reaction happens at the > sender - so these sentences assume the feedback mechanism described in the > same document. > > It seems strange to me to have to update these sentence (regarding how > congestion control mechanisms should react) for the purpose of L4S, which > relies on an entirely different feedback mechanism; reacting exactly as if > there would have been loss in response to an accurate ECN signal is just > completely weird. > > Rather, in the proposed update that we’re planning to do for the sake of > ABE (which assumes “normal” RFC3168-style feedback), we should > probably talk about the ECE mechanism "described in this document” or > something like that - and the L4S work should be able to (rightfully) > assume that the reaction in response to accurate ECN simply isn’t > defined yet. > I was assuming that this also was a likely way forward. > > To 2) => Procedurally, I just wonder, is it really necessary to > “deprecate” (replace?) an Experimental RFC? As for the technical > side of it, we could just require the L4S work to discuss the case of a > lying receiver in the Security Considerations section - there could be > various possibilities for dealing with that, I’d assume… (e.g. > monitoring the feedback after giving an ECN indication, in case of > symmetric paths) - I think Bob had other arguments; either way I don’t > see a huge issue here. > > Cheers, > Michael > It would be fine to declare one experiment finished and to start a new one: In that sense, if the WH sees a strong consensus that the IETF no longer needs an Experimental Spec, and that this no longer should be deployed, it can be replaced by a new RFC. In this case RFC 3540 is from TSVWG, so whoever wishes to discuss this should make the presentation there. I'm curious also to see which method the IETF will recommend to solve the problem(s) that ECN-Nonce attempted to solve. Gorry >> On 22. mai 2016, at 01.55, John Leslie wrote: >> >> (not that I in any way disagree; this seems like the best starting >> point for what I believe we should discuss:) >> >> Mirja K??hlewind wrote: >>> >>> You don't need a charter for a non-wg-forming BoF (which anyway >>> wouldn't >>> make sense). However, you should have a description of the BoF (which >>> clearly lays out the goals of the BoF/discussion that is expected at >>> the >>> BoF) >> >> It seems to me that we have two really-fundamental items: >> >> 1) How to relax the requirement that ECN-marking results in the "same" >> reaction as a drop; and >> >> 2) How to deprecate ECN-nonce, which encourages seemingly-random >> switching >> between ECT-0 and ECT-1. >> >> I don't believe it appropriate to try to change either of these in an >> Experimental status document. (And I think we'll get in trouble if we >> try.) >> >> Thus, I'd like to see a first deliverable be a Proposed Standard >> laying >> out ground-rules for (quite possibly multiple) Experimental status >> documents. >> I know I've seen a fairly wide range of proposals differing in details >> from >> L4S (some of them very dependent upon variations in delay); and it's >> hard >> to believe that nobody will still want to push for their idea. >> >> I'd like to see a new WG chartered to oversee the appropriate >> experiments. >> This really doesn't fit any existing WG on Bob's list; and IMHO it's the >> easiest path to gain widespread support. (Or do any of you disagree that >> a lot of folks would like to _do_something_ about latency?) >> >> As for the particulars of L4S, I like it: but that doesn't mean that >> _everybody_ will like it. To tell truth, it's a bit hard to >> understand... >> >> The question of how to proceed with the L4S experiment remains open; >> and I would see no problem in evaluating it under the WG to be formed. >> If we want to put that in our charter, I won't object; but I really >> don't >> want to get hung-up on those details before we get authorization to >> respond differently to ECN marking and some assurance that we can treat >> ECT-0 and ECT-1 differently. >> >> If we go this path, we can spend the BoF justifying the efforts to >> free up ECT-0 and ECT-1 without having to argue details during the BoF. >> >> -- >> John Leslie >> >> _______________________________________________ >> tcpPrague mailing list >> tcpPrague@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpprague > > _______________________________________________ > tcpPrague mailing list > tcpPrague@ietf.org > https://www.ietf.org/mailman/listinfo/tcpprague > From nobody Sun May 22 12:17:08 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67BDB12D55D for ; Sun, 22 May 2016 12:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.026 X-Spam-Level: X-Spam-Status: No, score=-4.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426] 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 gxkX1qSj25fR for ; Sun, 22 May 2016 12:17:06 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id EF84312D0A6 for ; Sun, 22 May 2016 12:17:05 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 62487C941D; Sun, 22 May 2016 15:17:00 -0400 (EDT) Date: Sun, 22 May 2016 15:17:00 -0400 From: John Leslie To: Michael Welzl Message-ID: <20160522191700.GA8413@verdi> References: <573C564E.1090201@bobbriscoe.net> <20160518170612.GA56178@verdi> <573DA385.8020703@bobbriscoe.net> <20160521233147.GA6947@verdi> <9C86240F-3E2B-4534-9140-48D8286176A7@ifi.uio.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9C86240F-3E2B-4534-9140-48D8286176A7@ifi.uio.no> User-Agent: Mutt/1.4.1i Archived-At: Cc: Bob Briscoe , TCP Prague List Subject: Re: [tcpPrague] Volunteers pls: L4S non-WG-forming BoF proposal cut-off approaching X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2016 19:17:07 -0000 Michael Welzl wrote: > (snip) > >>> {Note 1} Some of the deliverables would be brought to tcpm anyway, >>> because they are important for all TCP-derived congestion controls, not >>> just "TCP Prague". >>> For instance, the following two RTT-related items are particularly >>> important for L4S/"TCP Prague", but they are also important updates to >>> the base TCP cc [RFC5681] too. >>> 3-4) Scaling TCP's Congestion Window for Small Round Trip Times >>> 3-5) Reduce TCP / SCTCP / TCP Prague RTT-dependence >> >> This is almost off-topic. :^( >> >> The "small round-trip times" issue is pretty fundamental: TCP _doesn't_ >> reduce its congestion window below 2 (packets); so with enough classic-TCP >> senders, no AQM can possibly hold latency low. Bob has proposed a change; >> but it's a change to _every_ classic TCP sender. Myself, I'd rather not >> worry about this just yet... >> >> RTT-dependence is an inseparable part of TCP-as-we-know-it. I'd _much_ >> rather not tilt at that windmill quite yet??? > > So here???s the +1. I can???t see how it helps this work if we discuss > all the possible problems of the world and how it can possibly solve them. That's a trifle unfair to Bob: he included a bunch of things which are actually prerequsites to L4S working well. I don't disagree with Bob that these are important: I merely don't want to tie ourselves in knots trying to solve them at the outset. > Opening many cans of various worms - wouldn???t it be better to keep > things more focused? Exactly! I listed the things I think are necessary to show sufficient results to get folks believing the goal is worth the effort. I'd like to concentrate our efforts there; and get around-to the other details after we can show some big-I-Internet results. -- John Leslie From nobody Sun May 22 12:25:40 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A89F912D18D for ; Sun, 22 May 2016 12:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 xqITv4CHpqBx for ; Sun, 22 May 2016 12:25:36 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 AD1C212D0A6 for ; Sun, 22 May 2016 12:25:36 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1b4Z0G-0005G1-Ro; Sun, 22 May 2016 21:25:32 +0200 Received: from 3.134.189.109.customer.cdi.no ([109.189.134.3] helo=[192.168.0.103]) by mail-mx4.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1b4Z0G-00012B-6V; Sun, 22 May 2016 21:25:32 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Welzl In-Reply-To: <20160522191700.GA8413@verdi> Date: Sun, 22 May 2016 21:25:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <014B8A2F-2E8A-4312-8B95-F2F6584485EE@ifi.uio.no> References: <573C564E.1090201@bobbriscoe.net> <20160518170612.GA56178@verdi> <573DA385.8020703@bobbriscoe.net> <20160521233147.GA6947@verdi> <9C86240F-3E2B-4534-9140-48D8286176A7@ifi.uio.no> <20160522191700.GA8413@verdi> To: John Leslie X-Mailer: Apple Mail (2.3124) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 2 sum rcpts/h 7 sum msgs/h 3 total rcpts 41990 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 37487D2B4E725059015A5489F13029CE331C2C22 X-UiO-SPAM-Test: remote_host: 109.189.134.3 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 1056 max/h 14 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Bob Briscoe , TCP Prague List Subject: Re: [tcpPrague] Volunteers pls: L4S non-WG-forming BoF proposal cut-off approaching X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2016 19:25:38 -0000 > On 22. mai 2016, at 21.17, John Leslie wrote: >=20 > Michael Welzl wrote: >> (snip) >>=20 >>>> {Note 1} Some of the deliverables would be brought to tcpm anyway,=20= >>>> because they are important for all TCP-derived congestion controls, = not=20 >>>> just "TCP Prague". >>>> For instance, the following two RTT-related items are particularly=20= >>>> important for L4S/"TCP Prague", but they are also important updates = to=20 >>>> the base TCP cc [RFC5681] too. >>>> 3-4) Scaling TCP's Congestion Window for Small Round Trip Times >>>> 3-5) Reduce TCP / SCTCP / TCP Prague RTT-dependence >>>=20 >>> This is almost off-topic. :^( >>>=20 >>> The "small round-trip times" issue is pretty fundamental: TCP = _doesn't_ >>> reduce its congestion window below 2 (packets); so with enough = classic-TCP >>> senders, no AQM can possibly hold latency low. Bob has proposed a = change; >>> but it's a change to _every_ classic TCP sender. Myself, I'd rather = not >>> worry about this just yet... >>>=20 >>> RTT-dependence is an inseparable part of TCP-as-we-know-it. I'd = _much_ >>> rather not tilt at that windmill quite yet??? >>=20 >> So here???s the +1. I can???t see how it helps this work if we = discuss >> all the possible problems of the world and how it can possibly solve = them. >=20 > That's a trifle unfair to Bob: Wasn=E2=80=99t the intention =3D> au contraire=E2=80=A6 > he included a bunch of things which > are actually prerequsites to L4S working well. >=20 > I don't disagree with Bob that these are important: I merely don't > want to tie ourselves in knots trying to solve them at the outset. >=20 >> Opening many cans of various worms - wouldn???t it be better to keep >> things more focused? >=20 > Exactly! =E2=80=A6 that was my point. Cheers, MIchael >=20 > I listed the things I think are necessary to show sufficient results > to get folks believing the goal is worth the effort. I'd like to = concentrate > our efforts there; and get around-to the other details after we can = show > some big-I-Internet results. >=20 > -- > John Leslie From nobody Sun May 22 12:47:25 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA29912D1AF for ; Sun, 22 May 2016 12:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.026 X-Spam-Level: X-Spam-Status: No, score=-4.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426] 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 FmTE2klBSuGT for ; Sun, 22 May 2016 12:47:22 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id B79E512D119 for ; Sun, 22 May 2016 12:47:21 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id C8479C9417; Sun, 22 May 2016 15:47:18 -0400 (EDT) Date: Sun, 22 May 2016 15:47:18 -0400 From: John Leslie To: Michael Welzl Message-ID: <20160522194718.GB8413@verdi> References: <573C564E.1090201@bobbriscoe.net> <20160518170612.GA56178@verdi> <573DA385.8020703@bobbriscoe.net> <573DE5A9.70808@tik.ee.ethz.ch> <20160521235539.GB6947@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Archived-At: Cc: " Fairhurst" , grenville armitage , Bob Briscoe , Mirja K??hlewind , TCP Prague List , " Khademi" , John Leslie Subject: Re: [tcpPrague] Volunteers pls: L4S non-WG-forming BoF proposal cut-off approaching X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2016 19:47:24 -0000 Michael Welzl wrote: > > [adding the co-authors of the ABE draft] > > My thoughts regarding the two items that John mentions below: NB: I take 1) to mean: >> 1) How to relax the requirement that ECN-marking results in the "same" >> reaction as a drop; > To 1) => the problematic statements from RFC3168 are on the third slide > here: > https://www.ietf.org/proceedings/95/slides/slides-95-tsvwg-13.pdf > (sorry for forgetting to use slide numbers!) > > They talk about ???the indication of congestion??? and "the receipt by > an ECN-Capable transport of a single CE packet???. > The receiver gets this signal, but the congestion reaction happens at > the sender - so these sentences assume the feedback mechanism described > in the same document. More exactly, they assume some magical process, which _may_ be the feedback mechanism in the same document... > It seems strange to me to have to update these sentence (regarding how > congestion control mechanisms should react) for the purpose of L4S, > which relies on an entirely different feedback mechanism; reacting > exactly as if there would have been loss in response to an accurate > ECN signal is just completely weird. My concern is to get warnings where the folks which have to implement things will see them. "Same-as" has found its way into enough documents that the implementation of deprecating it is non-trivial. I don't want to discuss all those details (if we can avoid it); but I think we need to get the warning-labels out there. > Rather, in the proposed update that we???re planning to do for the > sake of ABE (which assumes ???normal??? RFC3168-style feedback), we > should probably talk about the ECE mechanism "described in this > document??? or something like that - and the L4S work should be able > to (rightfully) assume that the reaction in response to accurate ECN > simply isn???t defined yet. We mustn't assume that all implementors read all RFCs. Accurate-ECN _is_ essential to L4S working as intended; but what reason is there for folks designing the next generation of cable-modem to read and understand it? We need to find a way to ensure that folks designing such boxes understand it _does_ matter whether packets are dropped instead of ECE-marked; and that reasonable active-queue-management will desire different marking rules for ECT-1 packets vs. ECT-0 packets. I proposed a design-for-experiments document updating enough RFCs as a way to accomplish this: no doubt there are other ways; but we're ill-advised to say, "Well, they _should_ have known!" >> 2) How to deprecate ECN-nonce, which encourages seemingly-random switching >> between ECT-0 and ECT-1. > To 2) => Procedurally, I just wonder, is it really necessary to > ???deprecate??? (replace?) an Experimental RFC? IMHO, yes. I recognize there are many Experimental documents out there that have never been deprecated; nor have they resulted in a "Results of Experiment" documents. This leads to confusion which could have been easily avoided. In this particular case, we have gotten a bunch of additional documents saying "This is how to support ECN-nonce," giving no hints that ECN-nonce was intended as an Experiment which should long since have been concluded. IMHO, we do need such a formal statement, and it should "update" the list of RFCs which show "how to support" I suppose YMMV; but I wish you'd come up with some way for implementors to learn that ECN-nonce is dead. > As for the technical side of it, we could just require the L4S work to > discuss the case of a lying receiver in the Security Considerations > section - there could be various possibilities for dealing with that, > I???d assume??? (e.g. monitoring the feedback after giving an ECN > indication, in case of symmetric paths) - I think Bob had other > arguments; either way I don???t see a huge issue here. I'd be happy to see such Security Considerations; but it really won't substitute for a warning label (that ECN-nonce can't accomplish this). -- John Leslie From nobody Sun May 22 12:54:27 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7482512D1AF for ; Sun, 22 May 2016 12:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.026 X-Spam-Level: X-Spam-Status: No, score=-4.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426] 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 G-7PIfZff4R9 for ; Sun, 22 May 2016 12:54:24 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 8690012D0F9 for ; Sun, 22 May 2016 12:54:24 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id A19D7C9416; Sun, 22 May 2016 15:54:21 -0400 (EDT) Date: Sun, 22 May 2016 15:54:21 -0400 From: John Leslie To: gorry@erg.abdn.ac.uk Message-ID: <20160522195421.GC8413@verdi> References: <573C564E.1090201@bobbriscoe.net> <20160518170612.GA56178@verdi> <573DA385.8020703@bobbriscoe.net> <573DE5A9.70808@tik.ee.ethz.ch> <20160521235539.GB6947@verdi> <824594fe27ca29beab42ee5dccd9a534.squirrel@erg.abdn.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <824594fe27ca29beab42ee5dccd9a534.squirrel@erg.abdn.ac.uk> User-Agent: Mutt/1.4.1i Archived-At: Cc: Michael Welzl , grenville armitage , Bob Briscoe , Mirja K??hlewind , TCP Prague List , naeemk@ifi.uio.no Subject: Re: [tcpPrague] Volunteers pls: L4S non-WG-forming BoF proposal cut-off approaching X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2016 19:54:25 -0000 gorry@erg.abdn.ac.uk wrote: >... >> >> To 2) => Procedurally, I just wonder, is it really necessary to >> ???deprecate??? (replace?) an Experimental RFC? As for the technical >> side of it, we could just require the L4S work to discuss the case of a >> lying receiver in the Security Considerations section - there could be >> various possibilities for dealing with that, I???d assume??? (e.g. >> monitoring the feedback after giving an ECN indication, in case of >> symmetric paths) - I think Bob had other arguments; either way I don???t >> see a huge issue here. >> >> Cheers, >> Michael > > It would be fine to declare one experiment finished and to start a new > one: In that sense, if the WH sees a strong consensus that the IETF no > longer needs an Experimental Spec, and that this no longer should be > deployed, it can be replaced by a new RFC. That is certainly one way: I'm happy to defer to Mirja whether it is the best way... > I'm curious also to see which method the IETF will recommend to solve the > problem(s) that ECN-Nonce attempted to solve. Bob has mentioned several: I'd rather not _start_ that discussion myself. (We've avoided solving that for rather a few years so far: IMHO it's not our highest priority.) -- John Leslie From nobody Sun May 22 23:40:35 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B608A12D538 for ; Sun, 22 May 2016 23:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 1UAfH9qmrxSG for ; Sun, 22 May 2016 23:40:30 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 234C112D531 for ; Sun, 22 May 2016 23:40:30 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id BB62D8BEA06E7; Mon, 23 May 2016 06:40:25 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u4N6eOat003379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 May 2016 06:40:27 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u4N6eI6N011439 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 May 2016 08:40:24 +0200 Received: from [135.224.194.121] (135.239.27.40) by FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 23 May 2016 08:40:13 +0200 To: "De Schepper, Koen (Nokia - BE)" , Bob Briscoe , References: <573C9605.8080308@bobbriscoe.net> From: Ing-Jyh Tsang Message-ID: <1d2ff246-1584-f075-4ba3-91b5444379f0@nokia.com> Date: Mon, 23 May 2016 08:40:13 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------199D0C3BD1838506253AA52C" X-Originating-IP: [135.239.27.40] Archived-At: Subject: Re: [tcpPrague] Draft L4S deliverables list X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 06:40:33 -0000 --------------199D0C3BD1838506253AA52C Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit Hi Bob, I will help on 3-4, 3-5, 3-8, and 4 also looking at implementation. Cheers, Inton On 19/05/2016 10:59, De Schepper, Koen (Nokia - BE) wrote: > > Hi Bob, > > I want to help on 1, 2 and most of the topics in 3 mainly in the scope > of 4, with implementations for Linux. > > Koen. > > *From:*tcpPrague [mailto:tcpprague-bounces@ietf.org] *On Behalf Of > *Bob Briscoe > *Sent:* woensdag 18 mei 2016 18:19 > *To:* TCP Prague List > *Subject:* [tcpPrague] Draft L4S deliverables list > > Folks, > > Here's the table of potential deliverables that I presented in Buenos > Aires. I've started to add volunteer's names. > Pls continue... > > Each should probably be divided into implementation and drafting the > spec, but let's assume any volunteer will do both/either. > > > > > *Description* > > > > *Draft(s)* > > > > *Volunteers* > > > > *Target WG* > > 1) > > > > L4S identifier > > > > draft-briscoe-tsvwg-ecn-l4s-id > > > > authors on draft > > > > tsvwg? > > 2) > > > > The DualQ AQM > > > > draft-briscoe-aqm-dualq-coupled > > > > authors on draft > > > > aqm? > > > > > > > > *3)* > > > > *Scalable Transport* > > > > > > 3-1) > > > > Fall back to Reno/Cubic on loss > > > > > > Linux / tcpm > > 3-2) > > > > TCP ECN Feedback > > > > draft-ietf-tcpm-accurate-ecn > > > > authors on draft > > > > tcpm > > 3-4) > > > > Scaling TCP's Congestion Window for Small Round Trip Times > > > > > Bob Briscoe, Marcelo Bagnulo Braun > > > > tcpm? > > 3-5) > > > > Reduce TCP / SCTCP / TCP Prague RTT-dependence > > > > > > tcpm? > > 3-6) > > > > Smooth ECN feedback over flow's RTT, not RTT hard-coded for DC > > > > > > tcpm? > > 3-7) > > > > Fall back to Reno/Cubic if classic ECN bottleneck detected > > > > > > tcpm? > > 3-8) > > > > Faster-than-additive increase > > > > > Marcelo > > > > tcpm? > > 3-9) > > > > Less drastic exit from slow-start > > > > > Marcelo, Bob > > > > tcpm? > > > > > > > > 4) > > > > TCP Prague (for the Internet) > > > > > > tcpm? > > 5) > > > > DCTCP bis (for data centres - may be the same as TCP Prague) > > > > draft-ietf-tcpm-dctcp (bis) > > > > > tcpm? > > 6) > > > > "SCTP Prague" > > > > > > tcpm/tsvwg? > > 7) > > > > RMCAT Prague > > > > > > rmcat? > > > *Notes: > *A line can be drawn somewhere around 3-7) to indicate that everything > above is an essential safety feature (preventing starvation etc), > while everything below (up to 3-9) is a performance improvement. > > 4,5,6) are essentially wrap-ups of the relevant elements from 3-1) to > 3-9) for each different transport > 7) might require one draft for Nada, one for SCREAM, etc or it might > be possible to describe one simple delta for all RMCAT approaches. > > Whether we need all the bitty pieces 3-1) to 3-9) or whether we should > go straight for the wrap-up solutions, is up for discussion. > > > Bob > > > > -- > ________________________________________________________________ > Bob Briscoehttp://bobbriscoe.net/ > > > _______________________________________________ > tcpPrague mailing list > tcpPrague@ietf.org > https://www.ietf.org/mailman/listinfo/tcpprague --------------199D0C3BD1838506253AA52C Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit

Hi Bob,

I will help on 3-4, 3-5, 3-8, and 4 also looking at implementation.

Cheers,
Inton


On 19/05/2016 10:59, De Schepper, Koen (Nokia - BE) wrote:

Hi Bob,

I want to help on 1, 2 and most of the topics in 3 mainly in the scope of 4, with implementations for Linux.

Koen.

From: tcpPrague [mailto:tcpprague-bounces@ietf.org] On Behalf Of Bob Briscoe
Sent: woensdag 18 mei 2016 18:19
To: TCP Prague List
Subject: [tcpPrague] Draft L4S deliverables list

Folks,

Here's the table of potential deliverables that I presented in Buenos Aires. I've started to add volunteer's names.
Pls continue...

Each should probably be divided into implementation and drafting the spec, but let's assume any volunteer will do both/either.

Description

Draft(s)

Volunteers

Target WG

1)

L4S identifier

draft-briscoe-tsvwg-ecn-l4s-id

authors on draft

tsvwg?

2)

The DualQ AQM

draft-briscoe-aqm-dualq-coupled

authors on draft

aqm?





3)

Scalable Transport


3-1)

Fall back to Reno/Cubic on loss

Linux / tcpm

3-2)

TCP ECN Feedback

draft-ietf-tcpm-accurate-ecn

authors on draft

tcpm

3-4)

Scaling TCP's Congestion Window for Small Round Trip Times

Bob Briscoe, Marcelo Bagnulo Braun

tcpm?

3-5)

Reduce TCP / SCTCP / TCP Prague RTT-dependence

tcpm?

3-6)

Smooth ECN feedback over flow's RTT, not RTT hard-coded for DC

tcpm?

3-7)

Fall back to Reno/Cubic if classic ECN bottleneck detected

tcpm?

3-8)

Faster-than-additive increase

Marcelo

tcpm?

3-9)

Less drastic exit from slow-start

Marcelo, Bob

tcpm?





4)

TCP Prague (for the Internet)

tcpm?

5)

DCTCP bis (for data centres - may be the same as TCP Prague)

draft-ietf-tcpm-dctcp (bis)

tcpm?

6)

"SCTP Prague"

tcpm/tsvwg?

7)

RMCAT Prague

rmcat?


Notes:
A line can be drawn somewhere around 3-7) to indicate that everything above is an essential safety feature (preventing starvation etc), while everything below (up to 3-9) is a performance improvement.

4,5,6) are essentially wrap-ups of the relevant elements from 3-1) to 3-9) for each different transport
7) might require one draft for Nada, one for SCREAM, etc or it might be possible to describe one simple delta for all RMCAT approaches.

Whether we need all the bitty pieces 3-1) to 3-9) or whether we should go straight for the wrap-up solutions, is up for discussion.


Bob



-- 
________________________________________________________________
Bob Briscoe http://bobbriscoe.net/


_______________________________________________
tcpPrague mailing list
tcpPrague@ietf.org
https://www.ietf.org/mailman/listinfo/tcpprague

--------------199D0C3BD1838506253AA52C-- From nobody Mon May 23 04:48:10 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1282312D771 for ; Mon, 23 May 2016 04:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 VF3h3QJyNfdi for ; Mon, 23 May 2016 04:48:06 -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 BE8B212D75A for ; Mon, 23 May 2016 04:47:36 -0700 (PDT) Received: from dhcp-207-151.erg.abdn.ac.uk (dhcp-207-151.erg.abdn.ac.uk [139.133.207.151]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id B661A1B00279 for ; Mon, 23 May 2016 12:59:55 +0100 (BST) References: <573C564E.1090201@bobbriscoe.net> <20160518170612.GA56178@verdi> <573DA385.8020703@bobbriscoe.net> <573DE5A9.70808@tik.ee.ethz.ch> <20160521235539.GB6947@verdi> <824594fe27ca29beab42ee5dccd9a534.squirrel@erg.abdn.ac.uk> <20160522195421.GC8413@verdi> To: tcpprague@ietf.org From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. Message-ID: <5742EDD7.5020100@erg.abdn.ac.uk> Date: Mon, 23 May 2016 12:47:35 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160522195421.GC8413@verdi> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tcpPrague] Volunteers pls: L4S non-WG-forming BoF proposal cut-off approaching X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 11:48:10 -0000 On 22/05/2016 20:54, John Leslie wrote: > gorry@erg.abdn.ac.uk wrote: >> ... >>> >>> To 2) => Procedurally, I just wonder, is it really necessary to >>> ???deprecate??? (replace?) an Experimental RFC? As for the technical >>> side of it, we could just require the L4S work to discuss the case of a >>> lying receiver in the Security Considerations section - there could be >>> various possibilities for dealing with that, I???d assume??? (e.g. >>> monitoring the feedback after giving an ECN indication, in case of >>> symmetric paths) - I think Bob had other arguments; either way I don???t >>> see a huge issue here. >>> >>> Cheers, >>> Michael >> >> It would be fine to declare one experiment finished and to start a new >> one: In that sense, if the WG sees a strong consensus that the IETF no >> longer needs an Experimental Spec, and that this no longer should be >> deployed, it can be replaced by a new RFC. > > That is certainly one way: I'm happy to defer to Mirja whether it is > the best way... > It's Spencer (he's the TSVWG AD). >> I'm curious also to see which method the IETF will recommend to solve the >> problem(s) that ECN-Nonce attempted to solve. > > Bob has mentioned several: I'd rather not _start_ that discussion myself. > > (We've avoided solving that for rather a few years so far: IMHO it's > not our highest priority.) > I am aware of the proposals. > -- > John Leslie > > _______________________________________________ > tcpPrague mailing list > tcpPrague@ietf.org > https://www.ietf.org/mailman/listinfo/tcpprague > Gorry From nobody Mon May 23 06:29:09 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3553212D8D4 for ; Mon, 23 May 2016 06:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 wqGKTKgH_Bw5 for ; Mon, 23 May 2016 06:29:06 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 0ADBD12D8C1 for ; Mon, 23 May 2016 06:29:05 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 4BDF14F15FC6C; Mon, 23 May 2016 13:29:01 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u4NDT3K9031488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 May 2016 13:29:03 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u4NDT0rJ022248 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 May 2016 15:29:00 +0200 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.203]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Mon, 23 May 2016 15:28:18 +0200 From: "De Schepper, Koen (Nokia - BE)" To: Michael Welzl , John Leslie Thread-Topic: [tcpPrague] RTT-(in)dependent throughput Thread-Index: AQHRtPb3Dzn70zGWdU+I3qFX5bK0ig== Date: Mon, 23 May 2016 13:28:17 +0000 Message-ID: References: <573C564E.1090201@bobbriscoe.net> <20160518170612.GA56178@verdi> <573DA385.8020703@bobbriscoe.net> <20160521233147.GA6947@verdi> <9C86240F-3E2B-4534-9140-48D8286176A7@ifi.uio.no> In-Reply-To: <9C86240F-3E2B-4534-9140-48D8286176A7@ifi.uio.no> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Bob Briscoe , TCP Prague List Subject: Re: [tcpPrague] RTT-(in)dependent throughput X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 13:29:08 -0000 SGkgYWxsLA0KDQpKdXN0IHdhbnRlZCB0byBjbGFyaWZ5IHRoYXQgSSBzZWUgdGhlIFRDUC1QcmFn dWUgcmVxdWlyZW1lbnRzIHByaW1hcmlseSBhcHBsaWNhYmxlIGZvciBMNFMuIA0KDQoiTWF5YmUg c29tZSIgYWxzbyBtYWtlIHNlbnNlIHRvIGFwcGx5IHRvIGNsYXNzaWMgdGNwLCBidXQgZm9yIG1l IHRoaXMgaXMgbm90IHRoZSBtYWluIGdvYWwgYW5kIG9mdGVuIG5vdCBwb3NzaWJsZSBhbnltb3Jl LiBDbGFzc2ljIFRDUCB3b3JrcyB3ZWxsIChleGNlcHQgZm9yIGxvdyBsYXRlbmN5KSBpZiB3ZSBj b25maWd1cmUgYSBiaWcgZW5vdWdoIFEgaW4gdGhlIG5ldHdvcmsuIFRoZSBwcm9ibGVtcyBzdGFy dCBhcHBlYXJpbmcgaWYgdGhlIHF1ZXVlcyBnZXQgcmVkdWNlZC4NCg0KUmVsYXRlZCB0byB0aGUg UlRULShpbilkZXBlbmRlbmNlLCBpZiBhbiBBUU0gaXMgdGFyZ2V0aW5nIGEgZGVsYXkgb2YgMTAw bXMsIGEgZmxvdyB3aXRoIDEwMG1zIGJhc2UgUlRUIGNhbiBzdGlsbCBjb21wZXRlIHJlYXNvbmFi bHkgKHR3aWNlIGxlc3MgdGhyb3VnaHB1dCkgd2l0aCBhIGZsb3cgb2YgMW1zIGJhc2UgUlRULiAN Cg0KSWYgeW91IHNldCB0aGUgQVFNIHRvIDIwbXMsIHRoZSAxMDBtcyBmbG93IHdpbGwgZ2V0IDYg dGltZXMgbGVzcyB0aHJvdWdocHV0IHRoYW4gdGhlIDFtcyBmbG93LCBvciBzZWVuIG90aGVyd2lz ZSB5b3UgY2FuIHN1cHBvcnQgcmVhc29uYWJsZSBjb21wZXRpdGlvbiBmb3IgZmxvd3MgdXAgdG8g MjBtcyBiYXNlIFJUVC4NCg0KSWYgdGhlIEFRTSBpcyBzZXQgdG8gNW1zLCB5b3UgbWlnaHQgY29u c2lkZXIgRlFfKiB0byBzb2x2ZSB0aGUgUlRUIHVuZmFpcm5lc3MsIGFzIG90aGVyd2lzZSB5b3Vy IDEwMG1zIGZsb3cgZ2V0cyBhbG1vc3QgMjAgdGltZXMgbGVzcyB0aHJvdWdocHV0Lg0KDQpCdXQg aWYgeW91IHRhcmdldCBzdWIgbWlsbGlzZWNvbmQgcXVldWVzIGFzIGZvciBUQ1AtUHJhZ3VlLCBJ IHRoaW5rIHdlIHNob3VsZCBzb2x2ZSB0aGUgaXNzdWUgaW4gdGhlIGVuZC1zeXN0ZW0gKGVuZC0y LWVuZCBwcmluY2lwbGUpLiBXZSB3b3VsZCBmYWNlIHVwIHRvIDEwMCB0aW1lcyBsZXNzIHRocm91 Z2hwdXQgZm9yIDEwMG1zIGZsb3dzIGNvbXBldGluZyB3aXRoIDFtcyBmbG93cy4gQXMgd2UgYXJl IGRlZmluaW5nIGEgbmV3IHNlcnZpY2UsIHdlIHNob3VsZCBkbyB0aGlzIGZyb20gdGhlIGJlZ2lu bmluZywgYW5kIG5vdCBlbmQgdXAgaW4gYSBkZWFkbG9jayBzaXR1YXRpb24gYXMgd2UgYXJlIHdp dGggY2xhc3NpYyB0Y3AuIA0KDQpTbyBJIGFncmVlIGFsc28gdGhhdCB0aGlzIGlzIG5vdCBwb3Nz aWJsZSB0byBjaGFuZ2UgZm9yIGNsYXNzaWMgVENQLCBidXQgSSB0aGluayB3ZSBzaG91bGQgZm9y IFRDUC1QcmFndWUuDQoNClNhbWUgZm9yIG1pbmltdW0gMiBzZWdtZW50cywgd2hpY2ggZ3VhcmFu dGVlcyB0aGF0IGF0IGxlYXN0IDIgcGFja2V0cyBjYW4gYmUgc2VudCBwZXIgUlRUIGZvciBDbGFz c2ljIDEwMG1zIGZsb3dzIChhdCBsZWFzdCBpZiBFQ04gaXMgdXNlZCwgb3IgdGhlIGRyb3AgcHJv YmFiaWxpdHkgaXMgbm90IHRvbyBoaWdoIChpZiB0aGUgcXVldWVzIGFyZSBub3QgdG9vIHNtYWxs KSkuIFNvIGZvciBUQ1AtUHJhZ3VlLCBJIHByZWZlciB3ZSBkb24ndCBoYXZlIHN0YW5kaW5nIHF1 ZXVlcyB3aGljaCBjYW4ndCBiZSByZWR1Y2VkIChleGNlcHQgd2l0aCBkcm9wKS4NCg0KUmVnYXJk cywNCktvZW4uDQoNCg0KDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiB0Y3BQcmFndWUgW21haWx0bzp0Y3BwcmFndWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIE1pY2hhZWwNCj4gV2VsemwNCj4gU2VudDogem9uZGFnIDIyIG1laSAyMDE2IDEyOjE3DQo+ IFRvOiBKb2huIExlc2xpZQ0KPiBDYzogQm9iIEJyaXNjb2U7IFRDUCBQcmFndWUgTGlzdA0KPiBT dWJqZWN0OiBSZTogW3RjcFByYWd1ZV0gVm9sdW50ZWVycyBwbHM6IEw0UyBub24tV0ctZm9ybWlu ZyBCb0YgcHJvcG9zYWwNCj4gY3V0LW9mZiBhcHByb2FjaGluZw0KPiANCj4gSGkgYWxsLA0KPiAN Cj4gSnVzdCBvbmUgY29tbWVudDoNCj4gDQo+IChzbmlwKQ0KPiANCj4gPj4gMy01KSBSZWR1Y2Ug VENQIC8gU0NUQ1AgLyBUQ1AgUHJhZ3VlIFJUVC1kZXBlbmRlbmNlDQo+ID4NCj4gPiAgIFJUVC1k ZXBlbmRlbmNlIGlzIGFuIGluc2VwYXJhYmxlIHBhcnQgb2YgVENQLWFzLXdlLWtub3ctaXQuIEkn ZA0KPiBfbXVjaF8NCj4gPiByYXRoZXIgbm90IHRpbHQgYXQgdGhhdCB3aW5kbWlsbCBxdWl0ZSB5 ZXTigKYNCj4gDQo+IFNvIGhlcmXigJlzIHRoZSArMS4gIEkgY2Fu4oCZdCBzZWUgaG93IGl0IGhl bHBzIHRoaXMgd29yayBpZiB3ZSBkaXNjdXNzIGFsbA0KPiB0aGUgcG9zc2libGUgcHJvYmxlbXMg b2YgdGhlIHdvcmxkIGFuZCBob3cgaXQgY2FuIHBvc3NpYmx5IHNvbHZlIHRoZW0uDQo+IE9wZW5p bmcgbWFueSBjYW5zIG9mIHZhcmlvdXMgd29ybXMgLSB3b3VsZG7igJl0IGl0IGJlIGJldHRlciB0 byBrZWVwDQo+IHRoaW5ncyBtb3JlIGZvY3VzZWQ/DQo+IA0KDQoNCg0KDQoNCj4gQ2hlZXJzLA0K PiBNaWNoYWVsDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiB0Y3BQcmFndWUgbWFpbGluZyBsaXN0DQo+IHRjcFByYWd1ZUBpZXRmLm9yZw0K PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RjcHByYWd1ZQ0K From nobody Mon May 23 07:13:15 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5974E12D91C for ; Mon, 23 May 2016 07:13:13 -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 7Y4Qg7ouqnKC for ; Mon, 23 May 2016 07:13:11 -0700 (PDT) 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 3148612D913 for ; Mon, 23 May 2016 07:13:11 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id n63so108454569qkf.0 for ; Mon, 23 May 2016 07:13:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=R21V8xfEBYRxt5WwXFCMEk9HVk6SHaRS7NnlM2s989I=; b=d7qvAiPutvaNt4FpKIy0qcI77foYaT8H7oKzaPKVWI3GUw8M64IhIew21j0RYdc9JK ntYdQFoHJKwIsnxHHBA3sCEXiovCS8WMWf2Ai3IR/8BzCOcF+me6WKJ96SiJ4XmEBbHY SS+BKezCOMnqb3KUyzdahh69W11B8BG8XyX2UWZ9kgAW43zSXer6GM4KVPp6wfGg7LaE ww7f6HgKafLORXXI9ozehLraF6pfQYdlTjVv5bIv/hfrD0g2z+5oU7gfWqbZnJUS0bso 1tUkX/AkJn+3gtwMwH7lr2MvwebGT+05dhLMjOqbzOHxTEql8vjODXF4VkE+5/Z5cHKY YQ8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=R21V8xfEBYRxt5WwXFCMEk9HVk6SHaRS7NnlM2s989I=; b=DmyyXUwNQAkarC43a3WymnkPzS5l3Rf8Q41ZQCpzYF2YNjY09VsJLcxrZm5+knH2AL oSmeD6DUrLeqWN9V5y4PDD7UvZTX6KGTE/dJsKf/EhkldP0iGvlZpKLo/85ZcnIwMVdE r/8l31xsYEFJKi0QLS451LmxGKeUvv/U3PlQQzjWyFI3NAsNzx5qkWOKAsOLeMsffrGx f+upeDQ9fNr0zpbkOqeRxgI4n8tawTkRdn9RTJFLdSPMoK264toi8RrhsuRMf1LgVYLw JRkfV0co0IMU5vw1N0Y/GOyoSH4qp0Yp19S1Qy15ts6yse5Bd3mO/2Tt8tCrt5cuCsKF 7brw== X-Gm-Message-State: AOPr4FVv1Gufd64kJBFSStn1HVY6vcd8bgppgnp1YZh/q5r1yQQ39v+lNsrsOPvdbvq37Nfca121XWCy1VczKw== MIME-Version: 1.0 X-Received: by 10.55.17.19 with SMTP id b19mr16961122qkh.61.1464012790227; Mon, 23 May 2016 07:13:10 -0700 (PDT) Received: by 10.237.41.161 with HTTP; Mon, 23 May 2016 07:13:10 -0700 (PDT) Received: by 10.237.41.161 with HTTP; Mon, 23 May 2016 07:13:10 -0700 (PDT) In-Reply-To: <5742EDD7.5020100@erg.abdn.ac.uk> References: <573C564E.1090201@bobbriscoe.net> <20160518170612.GA56178@verdi> <573DA385.8020703@bobbriscoe.net> <573DE5A9.70808@tik.ee.ethz.ch> <20160521235539.GB6947@verdi> <824594fe27ca29beab42ee5dccd9a534.squirrel@erg.abdn.ac.uk> <20160522195421.GC8413@verdi> <5742EDD7.5020100@erg.abdn.ac.uk> Date: Mon, 23 May 2016 09:13:10 -0500 Message-ID: From: Spencer Dawkins at IETF To: gorry@erg.abdn.ac.uk Content-Type: multipart/alternative; boundary=001a114747944eeb3d0533830a6e Archived-At: Cc: tcpprague@ietf.org Subject: Re: [tcpPrague] Volunteers pls: L4S non-WG-forming BoF proposal cut-off approaching X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 14:13:13 -0000 --001a114747944eeb3d0533830a6e Content-Type: text/plain; charset=UTF-8 Hi, all, On May 23, 2016 06:48, "Gorry Fairhurst" wrote: > > On 22/05/2016 20:54, John Leslie wrote: >> >> gorry@erg.abdn.ac.uk wrote: >>> >>> ... >>>> >>>> >>>> To 2) => Procedurally, I just wonder, is it really necessary to >>>> ???deprecate??? (replace?) an Experimental RFC? As for the technical >>>> side of it, we could just require the L4S work to discuss the case of a >>>> lying receiver in the Security Considerations section - there could be >>>> various possibilities for dealing with that, I???d assume??? (e.g. >>>> monitoring the feedback after giving an ECN indication, in case of >>>> symmetric paths) - I think Bob had other arguments; either way I don???t >>>> see a huge issue here. >>>> >>>> Cheers, >>>> Michael >>> >>> >>> It would be fine to declare one experiment finished and to start a new >>> one: In that sense, if the WG sees a strong consensus that the IETF no >>> >>> longer needs an Experimental Spec, and that this no longer should be >>> deployed, it can be replaced by a new RFC. >> >> >> That is certainly one way: I'm happy to defer to Mirja whether it is >> the best way... >> > > It's Spencer (he's the TSVWG AD). True. I should also mention that Mirja and I talk ;-) Spencer >>> I'm curious also to see which method the IETF will recommend to solve the >>> problem(s) that ECN-Nonce attempted to solve. >> >> >> Bob has mentioned several: I'd rather not _start_ that discussion myself. >> >> (We've avoided solving that for rather a few years so far: IMHO it's >> not our highest priority.) >> > I am aware of the proposals. > > >> -- >> John Leslie >> >> _______________________________________________ >> tcpPrague mailing list >> tcpPrague@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpprague >> > Gorry > > > _______________________________________________ > tcpPrague mailing list > tcpPrague@ietf.org > https://www.ietf.org/mailman/listinfo/tcpprague --001a114747944eeb3d0533830a6e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi, all,

On May 23, 2016 06:48, "Gorry Fairhurst" <gorry@erg.abdn.ac.uk> wrote:
>
> On 22/05/2016 20:54, John Leslie wrote:
>>
>> gorry@erg.abdn.ac.uk &= lt;gorry@erg.abdn.ac.uk> wro= te:
>>>
>>> ...
>>>>
>>>>
>>>> To 2) =3D> Procedurally, I just wonder, is it really ne= cessary to
>>>> ???deprecate??? (replace?) an Experimental RFC?=C2=A0 =C2= =A0As for the technical
>>>> side of it, we could just require the L4S work to discuss = the case of a
>>>> lying receiver in the Security Considerations section - th= ere could be
>>>> various possibilities for dealing with that, I???d assume?= ??=C2=A0 (e.g.
>>>> monitoring the feedback after giving an ECN indication, in= case of
>>>> symmetric paths) - I think Bob had other arguments; either= way I don???t
>>>> see a huge issue here.
>>>>
>>>> Cheers,
>>>> Michael
>>>
>>>
>>> It would be fine to declare one experiment finished and to sta= rt a new
>>> one: In that sense, if the WG sees a strong consensus that the= IETF no
>>>
>>> longer needs an Experimental Spec, and that this no longer sho= uld be
>>> deployed, it can be replaced by a new RFC.
>>
>>
>> =C2=A0 =C2=A0 That is certainly one way: I'm happy to defer to= Mirja whether it is
>> the best way...
>>
>
> It's Spencer (he's the TSVWG AD).

True.

I should also mention that Mirja and I talk ;-)

Spencer

>>> I'm curious also to see which method the IE= TF will recommend to solve the
>>> problem(s) that ECN-Nonce attempted to solve.
>>
>>
>> =C2=A0 =C2=A0 Bob has mentioned several: I'd rather not _start= _ that discussion myself.
>>
>> =C2=A0 =C2=A0 (We've avoided solving that for rather a few yea= rs so far: IMHO it's
>> not our highest priority.)
>>
> I am aware of the proposals.
>
>
>> --
>> John Leslie <john@jlc.net&g= t;
>>
>> _______________________________________________
>> tcpPrague mailing list
>> tcpPrague@ietf.org
>> https:= //www.ietf.org/mailman/listinfo/tcpprague
>>
> Gorry
>
>
> _______________________________________________
> tcpPrague mailing list
> tcpPrague@ietf.org
> https://ww= w.ietf.org/mailman/listinfo/tcpprague

--001a114747944eeb3d0533830a6e--