Re: [tsvwg] L4S drafts: Next Steps

[Sebastian Moeller <[e-mail]>]

Hi Bob,

i believe nobody is asking for rocks (nor shrubberies) here, this is really about a convincing demonstration that the whole L4S design, consisting of network and protocol bits actually behaves like a coherent design and not two disjoint sub-projects that will never really harmonize? ATM what I see is you off-loading problems in the network bits by claiming the protocol will need to fix this up (RTT-bias comes to mind), and currently not even a single protocol convincingly demonstrates that the requirements a) can be met, and that b) doing so results in an L4S system that performs as promised without causing a safety issue for the existing internet.


	As it stands not even TCP Prague meaningfully fulfills the L4S transport requirements*, so we have zero proof that these requirements are actually feasible (I am simply going to ignore the questionnaire you send around, as neither party claimed, let alone demonstrated that their protocol actually meets all the requirements; these are essentially mere pre-implementation judgements whether people see conceptual stumbling blocks a priori, but as we all know the devil is in the details, so...)

Best Regards
	Sebastian


*) Partly because these requirements are unclear and impossible to fulfill, the RTT-bias thing comes to mind again, where you require the impossible from transport protocols (as that essentially requires faster than light travel) to fix up grave misdesigns in L4S' network bits core, the AQM which makes RTT-bias considerably worse as compared to the status quo (as seen in Pete's data))


> On Mar 11, 2021, at 23:07, Bob Briscoe <[e-mail]> wrote:
> 
> Jonathan,
> 
> The concern is requiring unnecessary work to prove things that are "bring me a different rock" exercises.
> 
> 
> Bob
> 
> On 11/03/2021 21:35, Jonathan Morton wrote:
>>> On 11 Mar, 2021, at 11:18 pm, Bob Briscoe <[e-mail]> wrote:
>>> 
>>> Where does the concern about transport protocol independence come from? No-one expects that to be a problem for L4S implementers.
>> If it's not expected to be a problem, then there shouldn't be any difficulty meeting the requirement, should there?
>> 
>> I think the concern arises because there is not yet even *one* complete implementation that meets *all* of the necessary requirements (including, for example, good behaviour when encountering an RFC-3168 AQM).  This points to the likely difficulty of a second implementer's task in replicating the feat.
>> 
>>  - Jonathan Morton
> 
> -- 
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/
>