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

[Yingzhen Qu <[e-mail]>]

Hi chairs,



Sorry for all the confusions and troubles here.



We originally requested a slot in TSVWG considering the in-band signaling
draft was presented there at last IETF. Since we didn't receive a
confirmation and also noticed that TSVWG already has a full schedule, hence
sent a request to TCPM. So far, no request sent to ICCRG yet.



We'd be happy to present it at either or both WGs. This congestion control
draft is a split of the in-band signaling draft per the comments we
received, and we plan to further split that draft based on comments
(potentially with one in Routing area focusing on ip signaling part). At
this IETF, we’ve requested to present the resource reservation using
in-band signaling in HotRFC lightning talk.



I’m also attaching the slides for the congestion control draft
presentation. Your comments are very much appreciated.



Title: A New Congestion Control in Bandwidth Guaranteed Network

Presenter: Yingzhen Qu (Huawei)

Time required (including Q/A): 10 mins

Draft: https://datatracker.ietf.org/doc/draft-han-tsvwg-cc/


Thanks,

Yingzhen

On Tue, Mar 13, 2018 at 3:21 AM, Gorry Fairhurst <[e-mail]>
wrote:

> Hi Chairs...
>
> I think we should coordinate:-)
>
> The history I know is (please add). I think I'd benefit from more thoughts
> by others.
>
> There is work in ETSI by various companies on next generation protocols.
> The work is diverse and most of it aims at significant changes to IP. I
> spoke with some people (by no means all) who attend, and they suggested at
> this time there was no consensus on what they thought was the best
> direction.
>
> We saw presentations on the overall architecture last IETF. There was
> discussions in 6man, intarea, tsvwg, and possibly other places. I saw
> significant push-back from others on the idea of introducing a new QoS
> model, but what they proposed was complex and had not been discussed much
> prior to the IETF meeting, so it may hard to understand by people.
>
> A key question is whether this can work on a path that does not include
> one specific vendor's equipment. What I understood was that it relied on
> OAM information about the path.  This phrase in the latest draft seems to
> agree with what I think was presented last IETF:
>     "When a sender receives the third duplicated ACK, but no previous
>       OAM congestion alarm has been received, then it is considered that
>       a segment is lost due to random failure not congestion.  In this
>       case the cwnd is not changed."
>
> 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.
>
> 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.
>
> They have now also requested time 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.
>
> Gorry
>
>
> On 13/03/2018, 09:45, Michael Tuexen wrote:
>
>> On 13. Mar 2018, at 07:43, Yingzhen Qu<[e-mail]>  wrote:
>>>
>>> Hi Michael,
>>>
>>> Sorry for the late response.
>>>
>>> Thanks for pointing out that we missed this important reference. You're
>>> right, Quick-Start and our proposal do have lots of similarities, for
>>> example both of them require that end-points and routers to work together.
>>> But they are also different in details. For example, in our proposal
>>> in-band signaling proposal bandwidth is reserved on routers along the path.
>>>
>>> In next version of this draft, We'll add discussions about RFC 4728 and
>>> 6077.
>>>
>>> BTW, can I request a slot to present this draft in TCPM if time allows?
>>>
>> How much time would you need?
>>
>> Best regards
>> Michael
>>
>>> Thanks,
>>> Yingzhen
>>>
>>> On Mon, Mar 5, 2018 at 12:09 AM, Scharf, Michael (Nokia - DE/Stuttgart)<
>>> [e-mail]>  wrote:
>>> I believe that this proposal is similar to QuickStart TCP (RFC 4782),
>>> which is not cited in draft-han-tsvwg-cc, and the reference is also missing
>>> in draft-han-6man-in-band-signaling-for-transport-qos.
>>>
>>>
>>>
>>> RFC 6077 explains some of the issues that an in-band signaling mechanism
>>> like Quick-Start has to solve. As far as I can tell, the fundamental
>>> challenge is neither the protocol specification nor a prototype
>>> implementation. For instance, it has been proven that QuickStart TCP can be
>>> implemented e.g. in network processors (see
>>> http://www.ikr.uni-stuttgart.de/Content/Publications/Archive
>>> /Sf_Diss_40112.pdf).
>>>
>>>
>>>
>>> So, when updating the documents, I suggest to add a discussion of how
>>> the open research issues explained in RFC 6077 are addressed.
>>>
>>>
>>>
>>> Michael
>>>
>>>
>>>
>>>
>>>
>>> From: Yingzhen Qu [mailto:[e-mail]]
>>> Sent: Sunday, March 04, 2018 9:59 PM
>>> To: [e-mail]
>>> Cc: Scharf, Michael (Nokia - DE/Stuttgart)<[e-mail]>;
>>> Thomas Nadeau<[e-mail]>; [e-mail]; Yingzhen Qu<
>>> [e-mail]>; [e-mail]; [e-mail]
>>> Subject: Re: [tsvwg] Agenda requests for TSVWG@IETF101
>>>
>>>
>>>
>>> Hi Gorry and Michael,
>>>
>>>
>>>
>>> Thanks for the suggestion, I'll request a presentation in ICCRG.
>>> Meanwhile, I think since the in-band signaling draft was presented in
>>> TSVWG, if time allows it still makes sense to present this draft in TSVWG.
>>>
>>>
>>>
>>> The in-band signaling draft covers lots of aspects, and the required
>>> changes include network layer and transport layer. We're working on
>>> updating the draft, and may break it into pieces to fit different WGs.
>>>
>>>
>>>
>>> Your comments and help are very much appreciated.
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Yingzhen
>>>
>>>
>>>
>>> On Sun, Mar 4, 2018 at 4:49 AM, Gorry Fairhurst<[e-mail]>
>>> wrote:
>>>
>>> I am unsure yet what the correct group of people world be to explore a
>>> "Bandwidth Guaranteed Network". The presentation last IETF looked like the
>>> work could imply a need for changes proposed to the network layer (using
>>> OAM exchnages) to set the sending rate and make those bandwidth
>>> reservations.  In the end, it could result in a protocol quite different to
>>> TCP, I think this sort of change may possibly have a home in TSVWG  - but
>>> first I'd agree with Michaeland would encourage a presentation of the
>>> problem statement in ICCRG to explore the issues.
>>>
>>> Gorry
>>>
>>> On 04/03/2018, 10:34, Scharf, Michael (Nokia - DE/Stuttgart) wrote:
>>>
>>>
>>> Hi all,
>>>
>>> > From the abstract: “…This draft proposes a new TCP congestion control
>>> algorithm used in bandwidth guaranteed networks.  It is an extension to the
>>> current TCP standards.”
>>>
>>> In the IETF, I believe the expertise for this specific document would be
>>> in TCPM, which in CC. If the authors are interested in feedback on the
>>> proposed mechanism, I would recommend to ask TCPM.
>>>
>>> Alternatively, corresponding research could perhaps be performed in the
>>> ICCRG. ICCRG has published RFC 6077 to document some of the open research
>>> issues in this space.
>>>
>>> Michael
>>>
>>> *From:*tsvwg [mailto:[e-mail]] *On Behalf Of *Yingzhen Qu
>>> *Sent:* Sunday, March 04, 2018 6:55 AM
>>> *To:* [e-mail]; [e-mail]
>>> *Cc:* Thomas Nadeau<[e-mail]>
>>> *Subject:* [tsvwg] Agenda requests for TSVWG@IETF101
>>>
>>> Dear Chairs,
>>>
>>> A new draft (The draft was suggested by TSVWG @IETF100) was just
>>> submitted, and we’d like to request a time slot to present it @IETF101.
>>>
>>> Title:A New Congestion Control in Bandwidth Guaranteed Network
>>>
>>> Presenter: Yingzhen Qu (Huawei)
>>>
>>> Time required (including Q/A): 10 mins
>>>
>>> Draft: https://datatracker.ietf.org/doc/draft-han-tsvwg-cc/
>>>
>>> If there is any question, please kindly let us know.
>>>
>>> Thanks,
>>>
>>> Yingzhen
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> tcpm mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>
>>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
>