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

[Ingemar Johansson S <[e-mail]>]

Hi

Please see inline, marked [IJ]
/Ingemar

> -----Original Message-----
> From: Lin Han [mailto:[e-mail]]
> Sent: den 14 mars 2018 22:22
> To: Ingemar Johansson S <[e-mail]>;
> [e-mail]
> Cc: [e-mail]; [e-mail]; '[e-mail]' <[e-mail]>
> Subject: RE: [tcpm] [tsvwg] inband signaling (was: Re: Agenda requests for
> TSVWG@IETF101)
> 
> Hi, Ingemar
> 
> Tanks for the comments, See inline answer
> 
> Best Regards
> 
> Lin
> 
> -----Original Message-----
> From: Ingemar Johansson S [mailto:[e-mail]]
> Sent: Wednesday, March 14, 2018 12:56 AM
> To: Lin Han <[e-mail]>; [e-mail]
> Cc: [e-mail]; [e-mail]; '[e-mail]' <[e-mail]>; Ingemar
> Johansson S <[e-mail]>
> Subject: Re: [tcpm] [tsvwg] inband signaling (was: Re: Agenda requests for
> TSVWG@IETF101)
> 
> Hi
> 
> This subject pops up every once in a while.
> [LH] You are right -:) But this time, we bring up this issue for the future
> applications like AR/VR, not for applications that current TCP works well. See
> the detailed analysis in draft-han-iccrg-arvr-transport-problem-00. We
> believe for the applications, such as AR/VR/TSN, that are much sensitive to
> congestion or delay, current technologies are hard to satisfy the
> requirement.
[IJ] Please have a look at the RITE project experiments https://riteproject.eu/, these show that you can achieve very short latency with L4S technology, L4S can in many ways coexist with diffserv and this draft outlines how the two can work together https://tools.ietf.org/pdf/draft-briscoe-tsvwg-l4s-diffserv-00.pdf . Given this I am not convinced why an inband QoS solution is needed for AR/VR.

> 
> I would like to add my perspective, given how I understand that 3GPP
> technology works. The 3GPP QoS framework can be used to offer for
> instance a Guaranteed bandwidth (GBR) to applications. The operation is that
> the "bearer" gets increased scheduling priority once the throughput is below
> the GBR value.
> In simulations I have verified that this framework can deliver a GBR to TCP
> flows when the network load increases, at least as long it is possible to push
> back other bearers with a lower priority. So, seen from my experience so far I
> am not fully confident that additional inband signaling is needed.
> [LH] Does it work well when the GW or eNodeB are congested? The purpose
> for in-band signaling is to guarantee network resource for a critical application
> no matter what happens. The congestion is the major problem for such
> requirement by current technology, because all flows can only share the
> bandwidth during congestion.
[IJ] As for eNB, the allocation of GBR/MBR comes with admission control. However because of physical limitations in terms of limited power coverage and/or radio interference, no in-band or out of band QoS signaling in the world can guarantee a given throughput in all conditions. It is all matter of prioritization of the available resource blocks, where each resources worth in terms of bits is dictated by the laws of Shannon, somewhat on steroids with the use of adaptive antenna beamforming. 

> 
> There can however be a benefit to e.g. determine an appropriate bitrate for
> a DASH session, depending on network load and/or coverage, but I would
> argue that out of band signaling is better in this case.
> [LH] One benefit of in-band signaling is it can provide the dynamic resource
> (like Q depth) to the source. By using this signal, we can distinguish
> congestion packet loss and random physical loss. It can increase the good-put
> for application as we described in the new draft.
[IJ] But isn't it better to use good AQMs instead as the goal should always be to avoid large standing queues ?. 

> 
> As regards to "worst case latency", I am not sure that I follow here, are we
> discussing TSN/Detnet technology here, general link failures, or is it about
> means to control the queue delay in the network ?. As to the latter, I believe
> that it is worthwhile to look more closely at L4S.
> [LH] Yes, we want to control the delay for specified flow by change the
> queue/scheduler parameters. We believe only through such very fine
> control, we can achieve the expected service from application. We are in talk
> with detnet to see if they want an alternative solution other than PWE. L4S
> still only provides a statistical bounded latency when all hosts are upgraded
> to support L4S. For our solution, we don't need to change hosts if they don't
> want to use new TCP.
[IJ] The L4S issue is that of deployment but you will face similar deployment issues with inband QoS signaling, probably worse. L4S is basically very simple technology whereas inband QoS implies more packet inspection and processing. 
And I believe that TSN/Detnet is a different story as it tries to achieve extremely tight scheduling, so far in confined domains.

> 
> Regards
> Ingemar Johansson
> 
> 
> > Message: 2
> > Date: Tue, 13 Mar 2018 19:27:18 +0000
> > From: Lin Han <[e-mail]>
> > To: Toerless Eckert <[e-mail]>, Gorry Fairhurst
> > 	<[e-mail]>
> > Cc: Thomas Nadeau <[e-mail]>, "[e-mail]"
> > 	<[e-mail]>,  "[e-mail]" <[e-mail]>, "Scharf,
> Michael
> > 	(Nokia - DE/Stuttgart)" <[e-mail]>,
> > 	"[e-mail]" <[e-mail]>, Katsushi Kobayashi
> > 	<[e-mail]>, Yingzhen Qu <[e-mail]>
> > Subject: Re: [tcpm] [tsvwg] inband signaling (was: Re: Agenda requests
> > 	for TSVWG@IETF101)
> > Message-ID:
> > 	<1D30AF33624CDD4A99E8C395069A2A162CDB9BA3@sjceml521-
> > mbs.china.huawei.com>
> >
> > Content-Type: text/plain; charset="us-ascii"
> >
> > Hi, Gorry/Toerless
> >
> > Here is some explanation and clarification for two drafts
> > (draft-han-tsvwg-cc and
> > draft-han-6man-in-band-signaling-for-transport-qos)
> >
> > 1. About draft-han-tsvwg-cc compared with other CC for bandwidth
> > guaranteed network, such as gTFRC.
> > draft-han-tsvwg-cc is a split draft from
> > draft-han-6man-in-band-signaling-for-
> > transport-qos . It proposes a new CC for a network if the TCP
> > session's bandwidth is guaranteed. Here the guaranteed  bandwidth is
> > per TCP session and described by PIR/CIR and given directly by TCP end
> user.
> >
> > 2. About TCP-QS and draft-han-6man-in-band-signaling-for-transport-qos
> > >From my understanding, TCP-QS and
> > >draft-han-6man-in-band-signaling-for-
> > transport-qos do have similarity, both are kind of using in-band
> > signaling for the resource reservation. But they still have big difference.
> > 1). draft-han-6man-in-band-signaling-for-transport-qos is more general
> > in- band signaling method, it not only applies to TCP, but also UDP or
> > other upper layer of protocol, even the draft only exemplifies the method
> to TCP.
> > 2). draft-han-6man-in-band-signaling-for-transport-qos provides
> > reserved resource for bandwidth and latency for the whole life of TCP
> > session. It gives more flavors and more granularity for the QoS
> > (unlike TCP-QS only has 16 values of starting bandwidth). Moreover, it
> > can support the "worst case latency" at each hop; also, it can support
> > the OAM to detect the congestion states, and support the "forwarding
> > state" for host to be notified in real-time about if the resource
> > reservation or QoS forwarding is interrupted by abnormal situation such as
> link/node failures.
> >
> > Best regards
> >
> > Lin
> >