Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C406312D7E5; Tue, 13 Mar 2018 12:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdO_GVjd4xdQ; Tue, 13 Mar 2018 12:25:30 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (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 C2D2012D7F4; Tue, 13 Mar 2018 12:25:29 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id y64so549892ywa.3; Tue, 13 Mar 2018 12:25:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HVY8XN4hLBcLLHIKYwTMc9JCC2bJBSAnBgOcrggDQck=; b=szBsgpntyJlzSZaoWmOR1NTS+OdIQqsHbxUEj1UwTOZcHZ0FbTnNaHmKAGqo8ztxbx xhDSxgjcbKmJ5GsLMwiRtkYnufdvA9nxiT2doRj0w1Peme7M1IcDxUtYAk1LivoF7z2Y xH6KQYjWW0WzpSJuCBIlu2/bWI7MfvEAX4MoGo/T0qGRGgkOx+JXBZhNAy0VTg/R90Rc ORWpkjR1KrFMRU1bmTdOFHwau4imx8AeW+L1er3qwhVaY7Hxkygq5cOOFZ4uTxI8bWoB DFysJLkhhG0qiwivj5BHpRK/x35hHtwqd7zRXDIrCvHpavZ4MTBmirfIeRQ0bxngxZCA yoBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HVY8XN4hLBcLLHIKYwTMc9JCC2bJBSAnBgOcrggDQck=; b=N73IDLqqT3+A0fIft/z1MflSzqDlWf6+b07w5NJhqgs+kjnjdGg1Hbp5az4bLeHwpB 7jvq37haUbEDukbHHg8mCLnhBW7ViE1PQIZ//WePpMg16nzQDA35/mJA7QNpXit9AOHL bim7B0ZWLsvAVXxDZnKNgKSdfKAmY9wVofg/I9wovpLxR6I+HIcNPNv9EViy8ShVIXzk x0vPrzkKc4IDUyIwMKcaVNe4SYWkwG6cTkx7GHYgw5SZvwh9aFzsV6XNx9R3iAA/7qLv eBIWxn05Apow9B5yIuC+lEBuql4qqPvJFpUQcynQskfvuZlfLVp9bBu2LkpYriN8uM02 uKcg== X-Gm-Message-State: AElRT7Hn4XavdgCm7caoq3hxyxO0HY8ZWuJ283IJXR4Uji7G3m+LiTgh YCYyZqS9yhDHaVwgsOHONRG9db7RfZY65T0zmI1M7w== X-Google-Smtp-Source: AG47ELv6ge+hu3e8p3jdIRbZnz7B1sYPb7KRo+ESqPsBY3SI2GrE3+FhCvVAy6m22A5mnNzjebhOAXMN7jETmDTv/Bg= X-Received: by 2002:a25:1a42:: with SMTP id a63-v6mr1467720yba.235.1520969128504; Tue, 13 Mar 2018 12:25:28 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:5f06:0:0:0:0:0 with HTTP; Tue, 13 Mar 2018 12:25:28 -0700 (PDT) In-Reply-To: <5AA7BB41.4070507@erg.abdn.ac.uk> References: <5A9BEB65.6010102@erg.abdn.ac.uk> <430A7C48-DA1D-4D73-AB40-F2B30A8E8580@lurchi.franken.de> <5AA7A614.3050706@erg.abdn.ac.uk> <5AA7BB41.4070507@erg.abdn.ac.uk> From: Spencer Dawkins at IETF Date: Tue, 13 Mar 2018 14:25:28 -0500 Message-ID: To: G Fairhurst Cc: "Scharf, Michael (Nokia - DE/Stuttgart)" , "tcpm-chairs@ietf.org" , "tsvwg-chairs@ietf.org" Content-Type: multipart/alternative; boundary="0000000000009e728b056750387c" Archived-At: Subject: Re: [tcpm] [tsvwg] Agenda requests for TSVWG@IETF101 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 19:25:34 -0000 --0000000000009e728b056750387c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Just to confirm, On Tue, Mar 13, 2018 at 6:51 AM, Gorry Fairhurst wrote: > On 13/03/2018, 11:23, Scharf, Michael (Nokia - DE/Stuttgart) wrote: > >> As for TSVWG, we have had quite a long discussion with the authors at th= e >>> meeting and after. The TSV chairs encouraged them to take the CC aspect= s >>> separately and explain why this method is better and detail what this >>> benefit >>> is and what is required in the router to allow this. We suggested an >>> initial talk >>> in ICCRG to present results and show *why* this is attractive. As far a= s >>> I know >>> they requested time to do this. >>> >> ICCRG is the right home for this. And the TCPM charter explicitly allows >> us to move topics there... >> >> I have written a PhD thesis on exactly this topic; we had a network >> processor implementation of Quick-Start, and our use cases was actually >> augmented/virtual reality... And I run into tons of fundamental issues 1= 0 >> years ago, which are not easy to solve and not even mentioned in the I-D= s. >> So I somehow feel qualified to give feedback on what they have to look a= t >> more in detail =F0=9F=98=89 >> >> They also requested time in TSVWG - but there's (as yet) been little >>> discssion >>> on the list, so we curently advise them to prepare a slide to show to >>> say why >>> people should read the draft. We have not decided (yet) to give time to >>> this >>> new framework. >>> >> I personally believe that for new ideas the IETF should give a >> presentation slot *once*. For a second presentation the bar should be >> higher. If the framework draft has been presented already in TSVWG, IMHO >> further discussion on that belongs now on the list. >> >> They have now also requested time in TCPM. >>> >> The draft is very specific about TCP congestion control, so in principle >> it belongs into TCPM. In general, I think TCPM should be open to new ide= as. >> But my own thinking is that this can be at best a "if time permits" >> presentation in TCPM. >> >> I don't know whethere this time they are also requesting slots some othe= r >>> places to discuss other aspects. >>> >>> I also suggested (informally) that they should try making a great short >>> presentation of how this is a new opportunity and whar has changed sinc= e >>> we last saw schemes proposed. I do see that there are significant >>> advances in >>> router forwarding hardware - and I suspect there could be similar ideas >>> in >>> cisco, etc.Would other vendors (or operators) be interested in >>> standardising >>> this? I think such a talk could be put to TSVAREA. >>> >> I am only at the IETF on Sunday evening and Monday morning. >> Unfortunately, I may not be in TSVAREA as I have to go back to the airpo= rt. >> >> I doubt that other people who are familiar with RTG and OPS area will >> show up in TSVAREA (but I may be wrong). It is pointless to discuss traf= fic >> engineering and OAM in router hardware without RTG area input. In RTG an= d >> OPS area, the level of multi-vendor support of a document can typically = be >> seen in the author list. >> >> Michael >> >> I suspect it is far too late to use TSVAREA for this at the coming IETF. > https://datatracker.ietf.org/meeting/101/materials/agenda-101-tsvarea looks pretty packed to me - it's a one-hour slot. > Actually, to be more clear --- I am **NOT** against some sort of evolutio= n > in the network, and figuring out how best transports interact with this. > Ditto. Spencer > I still have people working on this, I see newer router designs as more > inviting, I still see appetite to do this. But like you, I **KNOW** there > some big obtsacles and pitfalls. I am wondering how best to bring this so= rt > of work to the IETF and get good perspective on the problems and solution= s. > After PLUS was short down by Privacy, I'd hate the next new thing to be > shot down for the wrong reason. > > Gorry > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --0000000000009e728b056750387c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just to confirm,=C2=A0

On Tue, Mar 13, 2018 at 6:51 AM, Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
O= n 13/03/2018, 11:23, Scharf, Michael (Nokia - DE/Stuttgart) wrote:
As for TSVWG, we have had quite a long discussion with the authors at the meeting and after. The TSV chairs encouraged them to take the CC aspects separately and explain why this method is better and detail what this benef= it
is and what is required in the router to allow this. We suggested an initia= l talk
in ICCRG to present results and show *why* this is attractive. As far as I = know
they requested time to do this.
ICCRG is the right home for this. And the TCPM charter explicitly allows us= to move topics there...

I have written a PhD thesis on exactly this topic; we had a network process= or implementation of Quick-Start, and our use cases was actually augmented/= virtual reality... And I run into tons of fundamental issues 10 years ago, = which are not easy to solve and not even mentioned in the I-Ds. So I someho= w feel qualified to give feedback on what they have to look at more in deta= il =F0=9F=98=89

They also requested time in TSVWG - but there's (as yet) been little di= scssion
on the list, so we curently advise them to prepare a slide to show to say w= hy
people should read the draft. We have not decided (yet) to give time to thi= s
new framework.
I personally believe that for new ideas the IETF should give a presentation= slot *once*. For a second presentation the bar should be higher. If the fr= amework draft has been presented already in TSVWG, IMHO further discussion = on that belongs now on the list.

They have now also requested time in TCPM.
The draft is very specific about TCP congestion control, so in principle it= belongs into TCPM. In general, I think TCPM should be open to new ideas. B= ut my own thinking is that this can be at best a "if time permits"= ; presentation in TCPM.

I don't know whethere this time they are also requesting slots some oth= er
places to discuss other aspects.

I also suggested (informally) that they should try making a great short
presentation of how this is a new opportunity and whar has changed since we last saw schemes proposed. I do see that there are significant advances = in
router forwarding hardware - and I suspect there could be similar ideas in<= br> cisco, etc.Would other vendors (or operators) be interested in standardisin= g
this? I think such a talk could be put to TSVAREA.
I am only at the IETF on Sunday evening and Monday morning. Unfortunately, = I may not be in TSVAREA as I have to go back to the airport.

I doubt that other people who are familiar with RTG and OPS area will show = up in TSVAREA (but I may be wrong). It is pointless to discuss traffic engi= neering and OAM in router hardware without RTG area input. In RTG and OPS a= rea, the level of multi-vendor support of a document can typically be seen = in the author list.

Michael

I suspect it is far too late to use TSVAREA for this at the coming IETF.

https://datatracker.ietf.org/meeti= ng/101/materials/agenda-101-tsvarea looks pretty packed to me - it'= s a one-hour slot.=C2=A0
=C2=A0
Actually, to be more clear --- I am **NOT** against s= ome sort of evolution in the network, and figuring out how best transports = interact with this.

Ditto.=C2=A0
<= div>
Spencer
=C2=A0
I still have people working on this, I see newer ro= uter designs as more inviting, I still see appetite to do this. But like yo= u, I **KNOW** there some big obtsacles and pitfalls. I am wondering how bes= t to bring this sort of work to the IETF and get good perspective on the pr= oblems and solutions. After PLUS was short down by Privacy, I'd hate th= e next new thing to be shot down for the wrong reason.

Gorry


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

--0000000000009e728b056750387c--