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

[Tom Herbert <[e-mail]>]

On Thu, Mar 15, 2018 at 7:01 PM, Lin Han <[e-mail]> wrote:

> 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.
>
>
>
Hi Lin,

The draft does seem to be TCP centric. You might want to look at FAST
(draft-herbert-fast-00). It's similar in that it uses extension headers for
network signaling of things such as QoS, but is designed to be completely
transport protocol agnostic. In fact one of the goals of FAST is to not
have the network perform DPI to extract 5-tuples any more. With the use of
non-TCP protocols or increased use of encryption (tunnel mode IPsec) the
need or ability for the network to do DPI hopefully decreases (IMO a good
thing since DPI tends to be a source of protocol ossification). We still
want the same functionality though which is what FAST tries to provide.

Tom


> 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] <[e-mail]>]
> *Sent:* Friday, March 16, 2018 2:00 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, 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:
>
> [image: cid:image001.png@01D3BC8D.57335970]
>
>
>
>
>
> -----Original Message-----
> From: tsvwg [mailto:[e-mail] <[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
>
>
>
>
>