Re: [tcpm] [tsvwg] Agenda requests for TSVWG@IETF101

Hi folks!

I am puzzled as to why I receive this - has someone put me in bcc?  AFAIK, I’m not in tcpm-chairs, not in tsvwg-chairs, and I’m also happy to remind people that I’m *not* chairing ICCRG anymore!  :-)

Anyway, to me, this also sounds like ICCRG material - but I haven’t read the draft and so I probably shouldn’t even comment.
But FWIW, I’d enjoy seeing this in ICCRG. I might even ask something at the mic, just to see how that feels.

I’m cc’ing the ICCRG chair, Jana, because it seems that this should have reached him.

Jana - I actually even can’t fully figure out what these folks here are talking about: either this draft:
https://datatracker.ietf.org/doc/draft-han-tsvwg-cc <https://datatracker.ietf.org/doc/draft-han-tsvwg-cc>
or that draft:
https://tools.ietf.org/html/draft-lochin-ietf-tsvwg-gtfrc-02 <https://tools.ietf.org/html/draft-lochin-ietf-tsvwg-gtfrc-02>

I think it’s the upper one.

Cheers,
Michael

> On Mar 13, 2018, at 12:51 PM, Gorry Fairhurst <gorry@erg.abdn.ac.uk> 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 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 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 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 processor 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 somehow feel qualified to give feedback on what they have to look at more in detail 😉
>> 
>>> 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 ideas. 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 other
>>> 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
>>> 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 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 engineering and OAM in router hardware without RTG area input. In RTG and 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.
> 
> Actually, to be more clear --- I am **NOT** against some sort of evolution in the network, and figuring out how best transports interact with this.
> 
> 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 sort of work to the IETF and get good perspective on the problems and solutions. 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