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

[Lin Han <[e-mail]>]

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

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