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

[Lin Han <[e-mail]>]

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. 

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.

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.

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.

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
>