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

[Lin Han <[e-mail]>]

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@01D3BC87.670DC980]





-----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]>; 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)



> 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