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

[Toerless Eckert <[e-mail]>]

Michael:

IMHO, the goal is to establish the model of mixed inelastic and elastic CIR..PIR
traffic elasticity as an option for TCP. The problem is to define it in such a way that
it is implementable, and as you say there there are now many different CC schemes
for TCP. We choose Reno as a well known reference in the hope that others could
then pick up and adopt to more modern, more complex CC algorithms, whereas
the newer ones have likely a lot more intricacies and fewer folks who would know how
to adopt the goals in details to those algorithms (i may be wrong on this one).

Maybe using a rather older refeence CC scheme like reno to define an easily
implementable version of the CIR..PIR goal is not the right approach,
but the description shuold be more abstract ? Or just use as Emmanual did
rely on TFRC as a reference ? Given how i think ( i may be wrong) that TFRC is
not really applied to TCP, i thought another approch would have to be used.

Advice very much welcome.

The principles intended to be established are not really rocket science:

 - Constrain yourself to a max of PIR
 - Operate under expectation to have CIR guaranteed
   (expectation to be provided from other components)
   - fast-start to CIR, reduce only to CIR on bad congestion feedback.
   - When operating at/below CIR:
     - distinguish congestion from random loss
       - repair random loss. Keep rate at CIR.
       - break or revert to CIR=0 on congestion loss
       - optional (shared queue DSCP/PHB option)
         defend CIR against congestion from up to a point where its
	 likely to be an CIR admission failure and not bullying contenders
 - Operate unchanged in all other cases (eg: between CIR..PIR).

Cheers
    Toerless

On Fri, Mar 16, 2018 at 08:24:44AM +0000, Scharf, Michael (Nokia - DE/Stuttgart) wrote:
> Hi Lin,
> 
> Thanks a lot. I read from your explanation that a leased line would solve the performance problem. Leased lines are offered by service providers already. Have you compared the performance of your proposed TCP modification over an existing leased line service of a service provider? And have you compared the result with a modern TCP stack with CUBIC, IW10, and the like running over the same service, without having to guess a PIR/CIR? For which cases would your scheme provide a better service to the application compared to what TCP can do today?
> 
> I suggest to study real measurements to understand how much headroom for improvement indeed exists, as compared to what TCP congestion control already can do today without any new technology.
> 
> For instance, a single TCP connection scales up to multiple 10 Gbps, i.e., as far as I know it basically can reach the limit what a single computer can process with current processors. TCP works very well over short latencies since more than 20 years.
> 
> Thanks
> 
> Michael
> 
> 
> From: tsvwg [mailto:[e-mail]] On Behalf Of Lin Han
> Sent: Friday, March 16, 2018 3:02 AM
> To: Scharf, Michael (Nokia - DE/Stuttgart) <[e-mail]>; Toerless Eckert <[e-mail]>; Gorry Fairhurst <[e-mail]>
> Cc: Thomas Nadeau <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; Katsushi Kobayashi <[e-mail]>; Yingzhen Qu <[e-mail]>
> Subject: Re: [tsvwg] inband signaling (was: Re: Agenda requests for TSVWG@IETF101)
> 
> Hi, Michael
> 
> As described in the original draft draft-han-6man-in-band-signaling-for-transport-qos, the new method is not designed for the normal application that current TCP works well.. It does not try to replace or compete with TCP for most of current applications. It is designed for the scenario that the regular TCP cannot satisfy the requirement in terms of bandwidth or latency. I..e, ultra-high bandwidth or ultra-short latency.
> 
> For example, there is no networked AR/VR (with good quality) now since no network or transport technology can satisfy its unusual requirement (see detailed analysis in draft-han-iccrg-arvr-transport-problem-00). In order to provide such service, SP may need to dramatically increase network, link capacity and even topology. Currently, a user may be only able to get such service by a leased line, but it is too expensive for most of people.
> 
> When an application selects the PIR and CIR, it must know the consequence for the value. As you said, if PIR>>CIR, it means it's a very burst traffic, and using new method may not make sense since user should know for the rate above CIR, the behavior will be almost same as regular reno, and above PIR is worse than reno since it will be dropped.
> How to smartly select PIR/CIR is another topic and irrelevant to the CC algorithm.
> 
> Regards
> 
> Lin
> 
> From: Scharf, Michael (Nokia - DE/Stuttgart) [mailto:[e-mail]]
> Sent: Thursday, March 15, 2018 6:07 PM
> To: Lin Han <[e-mail]<mailto:[e-mail]>>; Toerless Eckert <[e-mail]<mailto:[e-mail]>>; Gorry Fairhurst <[e-mail]..uk<mailto:[e-mail]>>
> Cc: Thomas Nadeau <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Katsushi Kobayashi <[e-mail]<mailto:[e-mail]>>; Yingzhen Qu <[e-mail]<mailto:[e-mail]>>
> Subject: RE: [tsvwg] inband signaling (was: Re: Agenda requests for TSVWG@IETF101)
> 
> As I wrote already, I believe there will be scenarios where the TCP Reno congestion control will complete data transfers significantly faster than what you propose, i.e., your proposal results in worse performance.
> 
> I suggest to draw a picture with PIR>>CIR and a larger RTT. Then you will see that there will be cases in which TCP Reno outperforms what you suggest. Which raises the question why an application should setup a TCP session that will be slower than the default.
> 
> Michael
> 
> 
> 
> From: Lin Han [mailto:[e-mail]]
> Sent: Friday, March 16, 2018 2:00 AM
> To: Scharf, Michael (Nokia - DE/Stuttgart) <[e-mail]<mailto:[e-mail]>>; Toerless Eckert <[e-mail]<mailto:[e-mail]>>; Gorry Fairhurst <[e-mail]<mailto:[e-mail]>>
> Cc: Thomas Nadeau <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Katsushi Kobayashi <[e-mail]<mailto:[e-mail]>>; Yingzhen Qu <[e-mail]<mailto:[e-mail]>>
> Subject: RE: [tsvwg] inband signaling (was: Re: Agenda requests for TSVWG@IETF101)
> 
> 
> Hi, Scarf
> 
> 
> 
> For draft-han-tsvwg-cc, we have some assumptions
> 
> 1. User application setup TCP session with a given PIR/CIR,
> 
> 2. Network devices on the path will satisfy such expectation. In details, the traffic with the rate below CIR is always guaranteed to pass, and above PIR will be dropped; If the rate is between PIR and CIR, the traffic may be competing with others to get the resource.
> 
> This draft try to propose what we should change for the current CC for above scenarios, the picture below may explain more clearly for what is the difference of new algorithm with reno:
> 
> [cid:image001.png@01D3BC8D.57335970]
> 
> 
> 
> 
> 
> -----Original Message-----
> From: tsvwg [mailto:[e-mail]] On Behalf Of Scharf, Michael (Nokia - DE/Stuttgart)
> Sent: Thursday, March 15, 2018 5:34 PM
> To: Toerless Eckert <[e-mail]<mailto:[e-mail]>>; Gorry Fairhurst <[e-mail]<mailto:[e-mail]>>
> Cc: Thomas Nadeau <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Katsushi Kobayashi <[e-mail]<mailto:[e-mail]>>; Yingzhen Qu <[e-mail]<mailto:[e-mail]>>
> Subject: Re: [tsvwg] inband signaling (was: Re: Agenda requests for TSVWG@IETF101)
> 
> 
> 
> > 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
> 
> 
> 
> This is wrong. Section 4.4 in RFC 4782 is very related to draft-han-tsvwg-cc. Of specific interest is e.g. the handling of ssthresh. RFC 4782 also considers packet headers.
> 
> 
> 
> > 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.
> 
> 
> 
> No. Quick-Start only has benefits if it is enabled by the applications that can indeed leverage it, which is a subset of all TCP flows. If a host naively applies it to any TCP connection, there will be no benefit as most Quick-Start requests will be rejected. So the endpoint has a strong incentive to enable it only on these connections that actually leverage it. Actually doing this is a problem of its own. I have discussed this issue with AR/VR developers 10 years ago and it was non-trivial by then. It would be interesting to learn what has changed since then in the application developer community.
> 
> 
> 
> > Which raises a complete different scalability challenge to TCP quickstart...
> 
> 
> 
> Yep. Quick-Start can be implemented in a router without per-flow state and thus scales e.g. on network processors. 10 years ago we found that the key performance bottleneck in the fast path would be the state-synchronization between the different cores of a network processor. But as Quick-Start does not perform hard guarantees, this can be worked around.
> 
> 
> 
> I am not a hardware expert, any maybe state synchronization between many cores is cheaper these days. But I'd really like to understand how hard QoS guarantees for single TCP connections would be achieved e.g. on modern multi-core network processor (i.e., multiple TBit/s).
> 
> 
> 
> > 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.
> 
> 
> 
> In my experiments 10 years ago, there was little performance benefit of Quick-Start as compared to IW10, which was published in RFC 6928. My experiments are published in http://www.ikr.uni-stuttgart.de/Content/Publications/Archive/Sf_Diss_40112.pdf.
> 
> 
> 
> I strongly suggest to compare new congestion control schemes tot CUBIC+IW10 as baseline, and to show how much performance benefit one indeed gets, and at what risk and costs.
> 
> 
> 
> Michael
> 
> 
> 
> 



-- 
---
[e-mail]