Re: [tsvwg] [tcpm] draft-ietf-tsvwg-ecn-l4s-id

[Bob Briscoe <[e-mail]>]

Michael,

On 11/11/2019 18:16, Scharf, Michael wrote:
>
> So can you confirm that a TCP sender can use the L4S service without 
> implementing AccECN? I am asking again since there has been some 
> recent list discussion on that, e.g., given the points raised by 
> Sebastian. I am a bit lost here on what the future plan in L4S 
> actually is.
>
L4S needs fine-grained feedback, but not necessarily AccECN.
So, while AccECN is the way to do fine-grained feedback, L4S needs AccECN.

I took your question to be in a context where something else might have 
replaced AccECN in the future for fine-grained feedback. In that case, 
L4S would need that new shiny thing instead, and would not then need AccECN.

> And I still fail to understand why even the general idea of RACK 
> matters to AQM algorithms, traffic classifiers, or priority schedulers 
> for traffic with 1/p congestion control in a router. RACK has lots of 
> merits, but most of them are IMHO entirely unrelated to the vision of 
> L4S. I’d suggest to focus L4S on solving the key problems for traffic 
> with 1/p congestion control.
>

I've promised David Black a full answer to this. So pls see that.
But briefly, an important advance of L4S is scalable throughput (it's in 
the name).

It would be pointless to remove one scaling limitation if it was 
replaced by the 3 DupACK as a throughput limitation (Amdahl's law). In 
an ideal world, the two would be done separately. But L4S creates a 
clean-slate opportunity where there's a new queue and new CCs, and there 
is no downside to placing the time-units requirement on these senders 
that have to be updated anyway. Then future expts that might rely on all 
hosts using time-units will not be precluded.

This is all in the latest text in the appendix.


Bob
>
> Michael (with no hat)
>
> *From:*Bob Briscoe <[e-mail]>
> *Sent:* Monday, November 11, 2019 10:39 AM
> *To:* Scharf, Michael <[e-mail]>; 
> [e-mail]
> *Cc:* [e-mail]; [e-mail]
> *Subject:* Re: [tsvwg] draft-ietf-tsvwg-ecn-l4s-id
>
> Michael,
>
> On a similar question of dependency between experiments, I think you 
> also expressed concern that ecn-l4s-id depends on the RACK experiment. 
> However, ecn-l4s-id only refers to RACK informatively, because it only 
> uses the general idea behind RACK. Just as quic-recovery (stds track) 
> uses the general idea behind RACK (expt track) by referring to it 
> informatively.
>
>
>
> Bob
>
> On 04/11/2019 15:26, Bob Briscoe wrote:
>
>     Michael,
>
>     Thank you for pointing this out, many months ago now.
>
>     There is no formal dependency of draft-ietf-tsvwg-ecn-l4s-id on
>     AccECN, as explained below.
>
>     For any transport protocol to comply with ecn-l4s-id, it needs
>     sufficiently accurate feedback of the extent of CE marking on the
>     forward path. You pointing this out has made me realize that there
>     is a 'needs' that should be a 'MUST' in the spec:
>
>     4.2.  Prerequisite Transport Feedback
>
>     CURRENT:
>
>        In general, a scalable congestion control, needs feedback of the
>
>        extent of CE marking on the forward path.
>
>     PROPOSED:
>
>        In general,for a transport protocol to providescalable
>     congestion control,
>
>     it MUST providefeedback of the
>
>        extent of CE marking on the forward path.
>
>
>     However, ecn-l4s-id only specifies the requirements that any L4S
>     transport protocol would have to satisfy. It does not define a
>     transport protocol itself. So AccECN is not a normative ref. So I
>     am also altering the text a little further down, where it refers
>     to AccECN, as follows:
>
>     CURRENT:
>
>       TCP:  Support for accurate ECN feedback (AccECN
>
>           [I-D.ietf-tcpm-accurate-ecn  <https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-07#ref-I-D.ietf-tcpm-accurate-ecn>]) by both ends is a prerequisite for
>
>           scalable congestion control.
>
>     PROPOSED:
>
>       TCP:  Support for accurate ECN feedback (such as AccECN
>
>           [I-D.ietf-tcpm-accurate-ecn  <https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-07#ref-I-D.ietf-tcpm-accurate-ecn>]) by both ends is a prerequisite for
>
>           scalable congestion control.
>
>     Thanks again for pointing this out.
>
>
>           Dependencies between Experiments
>
>
>     The case of TCP Prague provides a counter-argument:
>
>     TCP Prague could be specified in one monolithic experimental spec.
>     Or it could be broken down into experimental components, and a top
>     level experimental spec that pulls them all together.
>
>     The latter option would create multiple dependencies of one
>     experiment on others. But IMHO such modularity is preferable to a
>     monolithic spec. Especially if some of the components might have
>     other uses outside of TCP Prague (which is exactly the case with
>     TCP Prague, e.g. AccECN, ECN++, RACK are all potentially parts of
>     the base TCP stack, and paced-chirping is potentially usable by
>     any other congestion control - these are all experimental
>     component parts).
>
>     As another example, BBR was written up as an experimental draft,
>     and the Linux implementation uses RACK (although not mentioned in
>     the draft) which is enabled by default in Linux.
>
>     Such modularity is good.
>
>
>     Bob
>
>     On 24/03/2019 19:15, Scharf, Michael wrote:
>
>         I have just parsed through draft-ietf-tsvwg-ecn-l4s-id-06 and
>         I run into the following sentence:
>
>         TCP:  Support for accurate ECN feedback (AccECN
>
>               [I-D.ietf-tcpm-accurate-ecn]) by both ends is a
>         prerequisite for
>
>               scalable congestion control.  Therefore, the presence of
>         ECT(1) in
>
>               the IP headers even in one direction of a TCP connection
>         will
>
>               imply that both ends support AccECN.  However, the
>         converse does
>
>               not apply.  So even if both ends support AccECN, either
>         of the two
>
>               ends can choose not to use a scalable congestion
>         control, whatever
>
>               the other end's choice.
>
>         Can the authors please clarify whether there is a normative
>         dependency of draft-ietf-tsvwg-ecn-l4s-id on
>         draft-ietf-tcpm-accurate-ecn?
>
>         If so, I think the formal dependency on implementing AccECN
>         has to be spelt out explicitly. In that case, I would be
>         looking for a statement of the sort "MUST/SHOULD/MAY implement
>         draft-ietf-tcpm-accurate-ecn" somewhere. If such a requirement
>         does not exist, I think the above paragraph is confusing.
>
>         As individual contributor, I want to note that I disagree with
>         mandatory dependencies between experiments. I have mentioned
>         in the past that I believe that different experiments must be
>         specified independently of each other and should be
>         implementable independently of each other, specifically also
>         to be able to fail independently of each other. It is possible
>         that I am in the rough part of the consensus. But I haven't
>         changed my mind.
>
>         Michael (as individual)
>
>
>
>     -- 
>
>     ________________________________________________________________
>
>     Bob Briscoe http://bobbriscoe.net/
>
>
>
> -- 
> ________________________________________________________________
> Bob Briscoehttp://bobbriscoe.net/
>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/