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

["Scharf, Michael" <[e-mail]>]

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.

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.

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 provide scalable congestion control,

   it MUST provide feedback 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 Briscoe                               http://bobbriscoe.net/