Re: [tcpm] [tsvwg] inband signaling (was: Re: Agenda requests for TSVWG@IETF101)

[Lin Han <[e-mail]>]

Hi, Gorry/Toerless

Here is some explanation and clarification for two drafts (draft-han-tsvwg-cc and draft-han-6man-in-band-signaling-for-transport-qos)

1. About draft-han-tsvwg-cc compared with other CC for bandwidth guaranteed network, such as gTFRC.
draft-han-tsvwg-cc is a split draft from draft-han-6man-in-band-signaling-for-transport-qos . It proposes a new CC for a network if the TCP session's bandwidth is guaranteed. Here the guaranteed  bandwidth is per TCP session and described by PIR/CIR and given directly by TCP end user. 

2. About TCP-QS and draft-han-6man-in-band-signaling-for-transport-qos
>From my understanding, TCP-QS and draft-han-6man-in-band-signaling-for-transport-qos do have similarity, both are kind of using in-band signaling for the resource reservation. But they still have big difference.
1). draft-han-6man-in-band-signaling-for-transport-qos is more general in-band signaling method, it not only applies to TCP, but also UDP or other upper layer of protocol, even the draft only exemplifies the method to TCP.
2). draft-han-6man-in-band-signaling-for-transport-qos provides reserved resource for bandwidth and latency for the whole life of TCP session. It gives more flavors and more granularity for the QoS (unlike TCP-QS only has 16 values of starting bandwidth). Moreover, it can support the "worst case latency" at each hop; also, it can support the OAM to detect the congestion states, and support the "forwarding state" for host to be notified in real-time about if the resource reservation or QoS forwarding is interrupted by abnormal situation such as link/node failures.

Best regards

Lin


-----Original Message-----
From: tsvwg [mailto:[e-mail]] On Behalf Of Toerless Eckert
Sent: Tuesday, March 13, 2018 9:49 AM
To: Gorry Fairhurst <[e-mail]>
Cc: Thomas Nadeau <[e-mail]>; [e-mail]; [e-mail]; Scharf, Michael (Nokia - DE/Stuttgart) <[e-mail]>; [e-mail]; Katsushi Kobayashi <[e-mail]>; Yingzhen Qu <[e-mail]>
Subject: Re: [tsvwg] inband signaling (was: Re: Agenda requests for TSVWG@IETF101)

Thanks, Gory, nice explanation

TCP Quickstart is rfc4782 btw. i think there was a buggy number in the thread.

TCP quickstart really relates IMHO primarily to draft-han-6man-in-band-signaling-for-transport-qos, but not to draft-han-tsvwg-cc. The latter one is really meant to modify TCP assuming a known guaranteed CIR - whatever mechanism is used to provide that guarantee.

TCP quickstart is an interesting example for inband signaling, which is what Lin's in-band-signaling draft does too. The main difference is that our draft focusses on high-value traffic where per-flow state is feasible and beneficial, if not necessary. And TCP quickstart seems more targeted to ANY TCP flow. Which raises a complete different scalability challenge to TCP quickstart.

This type of comparison discussion will go into draft updates on our side.

Would be interested in any more data points about the history of TCP quickstart, eg: where it was observed in the wild in deployments.

Cheers
   Toerless

On Tue, Mar 13, 2018 at 09:38:54AM +0000, Gorry Fairhurst wrote:
> Maybe I'm  saying what is obvious, but to be sure:
> 
> The way I see QS is:
> - The router tracks the unutilised link capacity at the current time, 
> and uses this as some estimate of what may be available to new flows 
> in the near future.
> - The router responds to QS requests and can accept them if there is 
> "unutilised capacity" remaining.
> - When accepted router updates it's count of the total unutilised 
> capacity reducing by the accepted QS requests. (i.e., Subsequent QS 
> requests in the same interval will currently have a smaller pool of 
> unutilised capacity available).
> - After the end of the interval all "QS requests" expire and the 
> router again makes a measure of the unutilised capacity at the current 
> time.
> 
> None of this implies a "reservation" of link resource in my thinking. 
> In QS, the whole link capacity is intended to be shared using 
> congestion control, and if  flows start to send more using normal CC 
> within the interval where QS is operating, they would simply receive a 
> larger share of the capacity. That is: QS request didn't "allocate" 
> any link resource.
> 
> Gorry
> 
> 
> On 13/03/2018, 06:58, Katsushi Kobayashi wrote:
> >Hi,
> >
> >I think TCP QS router on the path also reserves bandwidth resource, 
> >if it accepts a request.
> >
> >RFC4782 says:
> >   If the router approves the Quick-Start Request, this approval SHOULD
> >   be taken into account in the router's decision to accept or reject
> >   subsequent Quick-Start Requests (e.g., using a variable that tracks
> >   the recent aggregate of accepted Quick-Start Requests).
> >
> >
> >---
> >Katsushi Kobayashi
> >
> >>2018/03/13 ??????3:43???Yingzhen Qu <[e-mail] 
> >><mailto:[e-mail]>> ????????????:
> >>
> >>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?
> >>
> >>Thanks,
> >>Yingzhen
> >>
> >>On Mon, Mar 5, 2018 at 12:09 AM, Scharf, Michael (Nokia -
> >>DE/Stuttgart) <[e-mail] 
> >><mailto:[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
> >>    <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]
> >>    <mailto:[e-mail]>]
> >>    *Sent:* Sunday, March 04, 2018 9:59 PM
> >>    *To:* [e-mail] <mailto:[e-mail]>
> >>    *Cc:* Scharf, Michael (Nokia - DE/Stuttgart)
> >>    <[e-mail] <mailto:[e-mail]>>;
> >>    Thomas Nadeau <[e-mail]
> >>    <mailto:[e-mail]>>; [e-mail]
> >>    <mailto:[e-mail]>; Yingzhen Qu <[e-mail]
> >>    <mailto:[e-mail]>>; [e-mail]
> >>    <mailto:[e-mail]>; [e-mail]
> >>    <mailto:[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] <mailto:[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]
> >>            <mailto:[e-mail]>] *On Behalf Of *Yingzhen Qu
> >>            *Sent:* Sunday, March 04, 2018 6:55 AM
> >>            *To:* [e-mail] <mailto:[e-mail]>;
> >>            [e-mail] <mailto:[e-mail]>
> >>            *Cc:* Thomas Nadeau <[e-mail]
> >>            <mailto:[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/
> >>            <https://datatracker.ietf.org/doc/draft-han-tsvwg-cc/>
> >>
> >>            If there is any question, please kindly let us know.
> >>
> >>            Thanks,
> >>
> >>            Yingzhen
> >>
> >>
> >

--
---
[e-mail]