Re: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adoption"

[Bob Briscoe <[e-mail]>]

Tal,

Following up on Donald's responses as a co-author,...

On 08/01/2019 21:43, Donald Eastlake wrote:
> Hi Tal,
>
> On Mon, Jan 7, 2019 at 2:57 AM Tal Mizrahi <[e-mail]> wrote:
>> Hi,
>>
>> I reviewed the draft, and I believe it is worth pursuing in the working group.
> Thanks for the support.
>
>> Comments:
>>
>> - Section 1.3 / Section 4: these sections discuss how the ingress node (classifier) may react to the congestion. However, it seems that there may be a conflict if the egress node both propagates the ECN to the destination AND sends a congestion feedback to the ingress node. In this case traffic may be throttled by two nodes (traffic source and NSH classifier). It would be helpful if the draft clarifies whether these two behaviors are mutually exclusive, or how they coexist.
> That is a reasonable consideration and the draft should probably talk
> about it. I think some actions by the NSH classifier could cause
> problems but there are other NSH classifier actions that would be OK.
[BB] We've started covered to cover this in Section 1.3 
<https://tools.ietf.org/html/draft-eastlake-sfc-nsh-ecn-support-02#section-1.3>, 
where we list and discuss the three types of action at the domain 
ingress that would be reasonable in response to congestion. However, I 
agree this isn't sufficient to address your concern, so it would also be 
useful to say what type of ingress action would /not/ be appropriate. 
Perhaps adding the following text to the note after the 3 bullets 
(subject to agreement by co-authors):

    "Any action by the ingress to reduce congestion needs to allow
    sufficient time for the end-to-end congestion control loop to
    respond first, for instance by the ingress taking a smoothed average
    of the level of congestion signalled by feedback from the tunnel
    egress."

I can also reassure you for each specific case that we suggest:

 1. Policing: Policing based on congestion feedback is intended to take
    over if the load is unresponsive to congestion signalling forwarded
    towards the receiver. Therefore, if the end-to-end congestion
    control is doing its job, policing-based on congestion feedback
    should do nothing. So the two ought not to conflict.
    Congestion-based policing should only intervene if congestion
    becomes excessive.

    [Note that this is not the same as a rate policer (which doesn't
    need congestion feedback - it can see the rate locally, so it can
    police to a rate without feedback about congestion from other
    nodes). Typically, rate policing conservatively limits everyone's
    rates to limit the possibility of congestion downstream. The idea of
    congestion policing is that you don't need to police rates - you
    only police if the sum of all the traffic at any node exceeds
    capacity (and if the end-systems don't respond to the congestion
    themselves).]

 2. Upstream congestion feedback: I believe this is a sub-case of
    congestion-based-policing (1), where the ingress passes its signals
    to some other node that does the policing on its behalf.

 3. Re-direction: Traffic engineering is definitely a case where it has
    to move slowly, which gives time for the end-system congestion
    controls to respond. We already have a point about taking care to
    avoid flap, etc. But I think being more specific with the extra
    words above can only help.

>
>> - The draft implies that in a network that uses ECN-in-NSH the Ingress and Egress nodes must be ECN aware, while the SFFs and SFs may be ECN unaware, allowing interoperability with older SFF/SF nodes. I would suggest to state this explicitly in the introduction.
> OK.
>
>> - "It MAY instead be set to ECT(1) if the NSH domain supports the experimental L4S capability [RFC8311], [ecnL4S]."
>>    This sentence is confusing from an implementer's perspective. Does the "MAY" here allow interoperability between the two approaches (RFC3168/ RFC8311)? Please clarify in the draft whether ECN-in-NSH-aware nodes are expected to be implemented as defined in [RFC3168] or as in [RFC8311], or a combination of both.
> I agree we need to clarify that.
Let me get back to you on this one. I have to admit that I can't 
remember why we catered for L4S in the way written around table 2. I've 
checked back, and I actually wrote this part myself, but it looks wrong 
to me, which would be embarrassing. However, I need to check with my 
co-authors to confirm that.

Whatever, thanks for picking this up.


Bob

>
> Thanks,
> Donald
> ===============================
>   Donald E. Eastlake 3rd   [phone] (cell)
>   1424 Pro Shop Court, Davenport, FL 33896 USA
>   [e-mail]
>
>> Cheers,
>> Tal.
>>
>> On Thu, Jan 3, 2019 at 7:11 AM IETF Secretariat <[e-mail]> wrote:
>>>
>>> The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state
>>> Candidate for WG Adoption (entered by Joel Halpern)
>>>
>>> The document is available at
>>> https://datatracker.ietf.org/doc/draft-eastlake-sfc-nsh-ecn-support/
>>>
>>> Comment:
>>> This starts the WG call for adoption of this draft.
>>> Please respond to the list, indicating support for this as a work item of the
>>> working group with this document as the basis for the work, or objection to
>>> the working group adopting this item as a working group draft.
>>>
>>> The authors should confirm to the chairs and WG secretary that all IPR known
>>> to them relevant to this draft has been disclosed.
>>>
>>> The working group adoption call will last 2 weeks, ending at the end of the
>>> day on Thursday, January 17 2019 COB somewhere.
>>>
>>> Thank you,
>>> Joel

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