Re: [tsvwg] inband signaling

[Lin Han <[e-mail]>]

Hi, Emmanuel

Yes, this behavior can be changed easily, we just reduce the rate to CIR for more conservation and simpler implementation.

Thanks

Lin

From: Emmanuel Lochin [mailto:[e-mail]]
Sent: Tuesday, March 20, 2018 2:38 AM
To: Toerless Eckert <[e-mail]>; Lin Han <[e-mail]>
Cc: [e-mail]
Subject: Re: [tsvwg] inband signaling

Fine for me and thanks for your answers, I just wanted to understand the rationale of this design choice. Well, putting aside MaxBandwidthWND, I have another question with MinBandwidthWND.

Looking at the end of section 4.4 from your draft, ssthresh is always set to MinBandwidthWND (basically you set it to the CIR). However, depending on the values of CIR and PIR, after a congestion event, you might get a value of cwnd/2 higher than MinBandwidthWND. So I believe MinBandwidthWND should be equal to max(MinBandwidthWND, halving(cwnd)); to reach better TCP performance.

EL


Le 19/03/2018 à 12:19, Toerless Eckert a écrit :

Lin, Emmanuel:



This is all great deal, but shouldn't we try to up level this ?



In one instance we should just claim that the inband signaling

can easily support a variety of existing PHB/DSCP options we have

standardized. Such as the AF options with its resulting differences

in marking. It looks to me as if the discus you have is about the

AF model, but if i am wrong, maybe just circle back to which

existing marking model we're referring.



And of course, it would be worthwhile to document which parameters

of the inband signaling would be needed to support which currently

defined PHB/DSCP option.



If we are talking about some additional, new & better PHB/marking

strategy we see as useful, it would look more logical to me to

introduce describe this independent of an inband signaling option,

but of course, then also describe which parameters of the

inband signaling are required to support it.



[ Just wanting to avoid the impression as if the inband signaling

  is kinda trying to reinvent the IETF QoS universe, when in effekt

  its really about a more lightweight,faster,scalable and simplified

  alternative to RSVP signaling possible through the evolution

  of NPU technologies. ]



Cheers

    Toerless



On Mon, Mar 19, 2018 at 11:03:06AM +0000, Lin Han wrote:

Hi, Emmanuel



Thanks for your comments.



I guess everyone agrees the color of the packets for different range of rate of traffic : GREEN (rate<CIR); YELLOW (CIR<rate<PIR); and RED (rate>PIR).



Right now, our argument is the policy for traffic management at the hardware.

Our current TM policy is that



1.      Transmit GREEN, all time even when the egress buffer exceeds the pre-configured threshold



2.      Transmit YELLOW if the egress buffer is less than the threshold, discard YELLOW if buffer depth exceeds the threshold



3.      Discard the RED at the ingress, we drop it as early as possible to reduce the system burden in switch fabric.



Since CURRENTLY the RED packet will be dropped at the ingress, to prevent the re-transmit of RED packet and reduce the associated latency, we will do rate limit to the host to below the PIR in our CC algorithm. This can reduce the buffer bloat at egress, and reduce possible congestion and thus reduce all NEW TCP flow's worst case latency.



If we allow RED at the ingress, what should be behavior at egress, and how to differentiate it with YELLOW? Unless we introduce two thresholds, one for YELLOW and one for RED. This may have more complexity at hardware. In the implementation, buffer depth exceeding the threshold is also an indication of possible congestion, we have to report this as warning to host by OAM. BTW, in our implementation, all NEW TCP  share same egress buffer.



Literally PIR already means the maximum rate allowed, do we want to give more freedom (may still pass) to user? Actually, If user think the exceeding PIR cause drop may impact its throughput, he can easily increase PIR to get higher throughput.



I totally understand to allow RED will have higher link utilization for the flow, but the utilization is not the only target the design has to consider. Actually, we think the link utilization is the target of traditional TCP, the buffer bloat and latency should have higher priority in our design for NEW TCP.



I want to make it clear, our current CC algorithm is to adapt the current TM policy. We can easily change the TM design and CC algorithm. I want to hear what community thinks in this regard.







Regards



Lin







From: Emmanuel Lochin [mailto:[e-mail]]

Sent: Monday, March 19, 2018 2:20 AM

To: [e-mail]<mailto:[e-mail]>; Lin Han <[e-mail]><mailto:[e-mail]>

Subject: Re: [tsvwg] inband signaling



Dear Lin,



Looking at your scheme below, I reckon the choice to limit the cwnd progression at PIR must be optional as this could be inadequate following the policy used. For instance : if you used a two-rate three-color marker to policy your traffic (basically a dual-rate dual token bucket algorithm to assess my traffic against two rate limits) : when conforms to the CIR, the TRTCM marks green, then between CIR and PIR yellow and above the PIR red : authorizing excess traffic if there is room in the network. So you should have the possibility to both optionally discard packets or mark it : and in the second case, you should not limit the cwnd, otherwise this CC won't take benefit of the full capacity.



EL



Le 16/03/2018 à 01:59, Lin Han a écrit :



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@01D3BF2F.7F30A960]











-----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]><mailto:[e-mail]><mailto:[e-mail]>; Gorry Fairhurst <[e-mail]><mailto:[e-mail]><mailto:[e-mail]><mailto:[e-mail]>

Cc: Thomas Nadeau <[e-mail]><mailto:[e-mail]><mailto:[e-mail]><mailto:[e-mail]>; [e-mail]<mailto:[e-mail]><mailto:[e-mail]><mailto:[e-mail]>; [e-mail]<mailto:[e-mail]><mailto:[e-mail]><mailto:[e-mail]>; [e-mail]<mailto:[e-mail]><mailto:[e-mail]><mailto:[e-mail]>; Katsushi Kobayashi <[e-mail]><mailto:[e-mail]><mailto:[e-mail]><mailto:[e-mail]>; Yingzhen Qu <[e-mail]><mailto:[e-mail]><mailto:[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











--



Emmanuel LOCHIN



Professeur ISAE



ISAE SUPAERO - Institut Supérieur de l'Aéronautique et de l'Espace



10 avenue Edouard Belin - BP 54032 - 31055 TOULOUSE CEDEX 4 FRANCE -



http://www.isae-supaero.fr



Tel [phone] - Fax [phone]



Web : http://personnel.isae.fr/emmanuel-lochin/









--

Emmanuel LOCHIN

Professeur ISAE

ISAE SUPAERO - Institut Supérieur de l'Aéronautique et de l'Espace

10 avenue Edouard Belin - BP 54032 - 31055 TOULOUSE CEDEX 4 FRANCE -

http://www.isae-supaero.fr

Tel [phone] - Fax [phone]

Web : http://personnel.isae.fr/emmanuel-lochin/