Re: [iccrg] [tsvwg] L4S related activity in 3GPP

[Sebastian Moeller <[e-mail]>]

Hi Jake,

I guess my tone was more negative than it should have been, PC is a clever idea, and it would be great if it succeeds in the real world. More below in-line.


> On Nov 13, 2019, at 07:57, Holland, Jake <[e-mail]> wrote:
> 
> On 2019-11-10, 02:46, "Sebastian Moeller" <[e-mail]> wrote:
>> [SM] has any one actually tested paced chirping (PC) over real-life
>> bonded links? As far as I can see PC pretty much relies on a) little
>> to no re-ordering of packets (weird given that L4S also wants to allow
>> larger re-ordering tolerance by recommending/mandating the use of RACK)
>> and b) that the packet delivery time of each packet reflects a common
>> path characteristic (which is less true for a bonded link).
> 
> I'd certainly love to see paced chirping fleshed out.

	[SM] No objection. The promise of it is certainly interesting. What I would like to see first, before getting too excited is rigorous testing to demonstrate its robustness and functionality even under adverse conditions. Of the top of my head, here is a list of things that I would like to see tested:

1) robustness against bi-directional path saturation
2) robustness against asymmetric paths
3) robustness against bonded links (possibility of re-ordering and inter packet delay does not reflect a single patch characteristic) I believe paired-packet probes have similar issues.
4) effect of high prevalence of paced chirpers in the network (these are active probes, at what point do the probes of different flow start to interfere with each other and ist that problematic)
5) conceptually, if I understand correctly it actually measured return latency, while ideally it should measure one-way delays, what are the consequences of that mismatch.

Again, would great if this works reliably and robustly, but as far as I can see so far all we know is that it works under some conditions.


>  If there's a robust
> version,

	[SM] +1

> it seems a promising way to avoid overshooting on slow start for
> just about everyone (so maybe we could all get rid of that latency spike
> on scenario 5),

	[SM] In the new scenario 5? I guess there not re-defining CE would be the cleanest solution...

> and I'd think it could have applications even outside of
> slow start anywhere you have a way to back off before pushing to overflow
> (e.g. BBR, or something using SCE, as well as L4S).

	[SM] Yes, that is why getting it tested under adverse conditions seems like an important next step!

> 
> Of course as the paper said, it's not ready yet, but it does also seem
> potentially helpful for the use case of highly variable link throughput.

	[SM] Excuse my ignorance, but in its proposed role as slow start replacement, it would only trigger rarely (on flow start-up and on certain time-out conditions, no)?

> To me it seems worth keeping in mind and examining further, whether
> or not you think L4S with ECT(1) will end up being viable.

	[SM] I apologize for lumping to many things together in the referenced email, it is just that the whole L4S set of concepts and drafts, IHO all could do with more thorough testing...

Best Regards
	Sebastian

> 
> Best,
> Jake
> 
>