Subject: Re: [sfc] Regarding draft-eastlake-sfc-nsh-ecn-support adoption call

From: Donald Eastlake <[email-masked]>
Date: Wed, 6 Feb 2019 01:08:23 -0500

Hi Anoop,

I'm willing to consider removing a lot of this but I don't understand
what's wrong with Section 1.3, item (3). Say you are a provider of SFC
services to many clients and client session are relatively long lived
and the services required by a client session can be provided through
any one of multiple SFF paths. When a new client session starts,
wouldn't the classified want to have congestion information about the
SFF paths in use by existing client sessions when choosing the SFF
path to be used by the new session?

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 [email-masked]

On Mon, Jan 28, 2019 at 4:23 PM Anoop Ghanwani <[email-masked]> wrote:
>
> Hi Joel,
>
> If that is truly the case, then I think Sections 1.3 and 4 should be removed.
>
> Otherwise, I myself am not clear what 1.3 and 4 are trying to
> accomplish and therefore would need clarification on that from the
> authors.
>
> Thanks,
> Anoop
>
> On Mon, Jan 28, 2019 at 1:20 PM Joel Halpern Direct
> <[email-masked]> wrote:
> >
> > I am pretty sure that what is intended is exactly what you say you
> > support, namely simple propagation of the information for the ECN
> > control loop, not a new loop.
> >
> > Can you suggest additional or modified owrding for the document to help
> > make this clear to readers?
> >
> > Thank you,
> > Joel
> >
> > On 1/28/19 4:18 PM, Anoop Ghanwani wrote:
> > > I read the draft and had a clarification question about Section 1.3
> > > and Section 4.
> > >
> > > Is the draft suggestion an alternate congestion control mechanism
> > > between tunnel ingress and tunnel egress which is working separately
> > > from end-to-end congestion control that requires ECN?
> > >
> > > If it's just about propagation of bits for the original feedback loop
> > > (i.e. before the tunnel header is added), I support the draft.  If
> > > it's attempting to define a new congestion feedback loop and
> > > mechanism, I think it may need more discussion.
> > >
> > > Thanks,
> > > Anoop
> > >
> > > On Wed, Jan 23, 2019 at 3:14 PM Joel M. Halpern <[email-masked]> wrote:
> > >>
> > >> While the time for the call has completed, I would like to see the
> > >> current discussion resolve before judging the adoption as chair (with Jim).
> > >> As a corollary, if anyone who has not spoken up has an opinion about the
> > >> adoption, it is still VERY helpful if you speak up.  Please provide
> > >> motivation for your response.
> > >>
> > >> If things do not resolve clearly on their own, the chairs will (as is
> > >> required) reach a determination anyway, but WG clarity is preferred.
> > >>
> > >> Thank you,
> > >> Joel
> > >>
> > >> _______________________________________________
> > >> sfc mailing list
> > >> [email-masked]
> > >> https://www.ietf.org/mailman/listinfo/sfc
>
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc

---

From: Anoop Ghanwani <[email-masked]>
Date: Thu, 7 Feb 2019 08:54:01 -0800

Hi Donald,

The functions are useful.  I just think they need more discussion before it
can be put in a WG document.  What is being suggested would be useful for
any tunneling technology, not just SFC.  And that's why it would need wider
discussion as to what information should be fed to the tunnel ingress.

A couple of issues for example:
- How does one treat ECT vs non-ECT sessions when making these decisions?
- How do we know the feedback is accurate if there are no ECT sessions?

The document becomes a lot more straightforward if all it is dealing with
is propagation of ECN bits from inner to outer header and vice versa.

Thanks,
Anoop

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 7 Feb 2019 12:17:49 -0500

Isn't a lot of that general discussion already captured in RFC 6040?

Yours,
Joel

On 2/7/19 11:54 AM, Anoop Ghanwani wrote:
> Hi Donald,
> 
> The functions are useful.  I just think they need more discussion before 
> it can be put in a WG document.  What is being suggested would be useful 
> for any tunneling technology, not just SFC.  And that's why it would 
> need wider discussion as to what information should be fed to the tunnel 
> ingress.
> 
> The document becomes a lot more straightforward if all it is dealing 
> with is propagation of ECN bits from inner to outer header and vice versa.
> 
> Thanks,
> Anoop
> 
> On Tue, Feb 5, 2019 at 10:08 PM Donald Eastlake <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hi Anoop,
> 
>     [email-masked] <mailto:[email-masked]>
> 
>     On Mon, Jan 28, 2019 at 4:23 PM Anoop Ghanwani
>     <[email-masked] <mailto:[email-masked]>> wrote:
>      >
>      > Hi Joel,
>      >
>      > <[email-masked] <mailto:[email-masked]>>
>     wrote:
>      > >
>      > > > On Wed, Jan 23, 2019 at 3:14 PM Joel M. Halpern
>     <[email-masked] <mailto:[email-masked]>> wrote:
>      > > >>
>      > > >> [email-masked] <mailto:[email-masked]>
>      > [email-masked] <mailto:[email-masked]>

---

From: Anoop Ghanwani <[email-masked]>
Date: Thu, 7 Feb 2019 10:10:19 -0800

Hi Joel,

I'm specifically referring to how the tunnel ingress should react to
congestion reports in terms of traffic engineering (selecting one tunnel
over another), which is the part that Donald is trying to retain in the
draft.

Is that what you're referring to?  If so, can you point to a specific
section in RFC 6040?  I took a quick look and I'm not able to find anything
about that.  All I see there is about propagation of ECN bits.

Thanks,
Anoop

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 7 Feb 2019 14:20:29 -0500

I had not understood that you meant specifically the tunnel congestion 
feedback.  I see that there is already a normative reference to
https://tools.ietf.org/html/draft-ietf-tsvwg-tunnel-congestion-feedback-06

While that normative reference may create problems for completing the 
work, I do not see it as a problem for the working group adopting the 
document?  If TSVWG ends up not advancing that document, then presumably 
the corresponding sections o fthis document would be removed?

Yours,
Joel

On 2/7/19 1:10 PM, Anoop Ghanwani wrote:
> section in RFC 6040?  I took a quick look and I'm not able to find 
> anything about that.  All I see there is about propagation of ECN bits.
> 
> Thanks,
> Anoop
> 
> On Thu, Feb 7, 2019 at 9:17 AM Joel M. Halpern <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     <mailto:[email-masked]>
>      > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >
>      >     Hi Anoop,
>      >
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >
>      >     <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >      >
>      >      > Hi Joel,
>      >      >
>      >      > If that is truly the case, then I think Sections 1.3 and 4
>     should
>      >     be removed.
>      >      >
>      >      > Otherwise, I myself am not clear what 1.3 and 4 are trying to
>      >      > accomplish and therefore would need clarification on that
>     from the
>      >      > authors.
>      >      >
>      >      > Thanks,
>      >      > Anoop
>      >      >
>      >      > On Mon, Jan 28, 2019 at 1:20 PM Joel Halpern Direct
>      >      > <[email-masked]
>     <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>      >     wrote:
>      >      > >
>      >      > > I am pretty sure that what is intended is exactly what
>     you say you
>      >      > > support, namely simple propagation of the information
>     for the ECN
>      >      > > control loop, not a new loop.
>      >      > >
>      >      > > Can you suggest additional or modified owrding for the
>     document
>      >     to help
>      >      > > make this clear to readers?
>      >      > >
>      >      > > Thank you,
>      >      > > Joel
>      >      > >
>      >      > > On 1/28/19 4:18 PM, Anoop Ghanwani wrote:
>      >      > > > I read the draft and had a clarification question about
>      >     Section 1.3
>      >      > > > and Section 4.
>      >      > > >
>      >      > > > Is the draft suggestion an alternate congestion
>     control mechanism
>      >      > > > between tunnel ingress and tunnel egress which is working
>      >     separately
>      >      > > > from end-to-end congestion control that requires ECN?
>      >      > > >
>      >      > > > If it's just about propagation of bits for the original
>      >     feedback loop
>      >      > > > (i.e. before the tunnel header is added), I support the
>      >     draft.  If
>      >      > > > it's attempting to define a new congestion feedback
>     loop and
>      >      > > > mechanism, I think it may need more discussion.
>      >      > > >
>      >      > > > Thanks,
>      >      > > > Anoop
>      >      > > >
>      >      > > > On Wed, Jan 23, 2019 at 3:14 PM Joel M. Halpern
>      >     <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >      > > >>
>      >      > > >> While the time for the call has completed, I would
>     like to
>      >     see the
>      >      > > >> current discussion resolve before judging the adoption as
>      >     chair (with Jim).
>      >      > > >> As a corollary, if anyone who has not spoken up has an
>      >     opinion about the
>      >      > > >> adoption, it is still VERY helpful if you speak up. 
>     Please
>      >     provide
>      >      > > >> motivation for your response.
>      >      > > >>
>      >      > > >> If things do not resolve clearly on their own, the chairs
>      >     will (as is
>      >      > > >> required) reach a determination anyway, but WG clarity is
>      >     preferred.
>      >      > > >>
>      >      > > >> Thank you,
>      >      > > >> Joel
>      >      > > >>
>      >      > > >> _______________________________________________
>      >      > > >> sfc mailing list
>      >      > > >> [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >      > > >> https://www.ietf.org/mailman/listinfo/sfc
>      >      >
>      >      > _______________________________________________
>      >      > sfc mailing list
>      >      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      >      > https://www.ietf.org/mailman/listinfo/sfc
>      >
>      >

---

From: Anoop Ghanwani <[email-masked]>
Date: Thu, 7 Feb 2019 15:03:39 -0800

Hi Joel,

OK, I can see a case for leaving it in.

Thanks,
Anoop

On Thu, Feb 7, 2019 at 11:20 AM Joel M. Halpern <[email-masked]> wrote:

> >      >      > If that is truly the case, then I think Sections 1.3 and 4
> >     should
> >      >     be removed.
> >      >      >
> >      >      > <[email-masked]
> >      >      > > Can you suggest additional or modified owrding for the
> >     document
> >      >     to help
> >      >      > > > between tunnel ingress and tunnel egress which is
> working
> >      >     separately
> >      >      > > >> While the time for the call has completed, I would
> >     like to
> >      >     see the
> >      >      > > >> current discussion resolve before judging the
> adoption as
> >      >     chair (with Jim).
> >      >      > > >> adoption, it is still VERY helpful if you speak up.
> >     Please
> >      >     provide
> >      >      > > >> If things do not resolve clearly on their own, the
> chairs
> >      >     will (as is
> >      >      > > >> required) reach a determination anyway, but WG
> clarity is
> >      >     preferred.
> >      >      > > >>
> >      >      > > >> Thank you,
> >      >      > > >> Joel
> >      >      > > >>
> >      >      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> >     <mailto:[email-masked]>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 7 Feb 2019 19:04:17 -0500

Okay.  With that, as chair I conclude that the working group has adopted 
this document.  Authors, please resubmit as draft-ietf-sfc-nsh-ecn-support.

Yours,
Joel

On 2/7/19 6:03 PM, Anoop Ghanwani wrote:
> On Thu, Feb 7, 2019 at 11:20 AM Joel M. Halpern <[email-masked] 
>      > On Thu, Feb 7, 2019 at 9:17 AM Joel M. Halpern
>      >      > Hi Donald,
>      >      > The functions are useful.  I just think they need more
>     discussion
>      >     before
>      >      > it can be put in a WG document.  What is being suggested
>     would be
>      >     useful
>      >      > for any tunneling technology, not just SFC.  And that's
>     why it would
>      >      > need wider discussion as to what information should be fed
>     to the
>      >     tunnel
>      >      > ingress.
>      >      >
>      >      > A couple of issues for example:
>      >      > - How does one treat ECT vs non-ECT sessions when making these
>      >     decisions?
>      >      > - How do we know the feedback is accurate if there are no ECT
>      >     sessions?
>      >      >
>      >      > The document becomes a lot more straightforward if all it
>     is dealing
>      >      > with is propagation of ECN bits from inner to outer header and
>      >     vice versa.
>      >      >
>      >      > Thanks,
>      >      > Anoop
>      >      >
>      >      > On Tue, Feb 5, 2019 at 10:08 PM Donald Eastlake
>     <[email-masked] <mailto:[email-masked]>
>      >      > <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
>      >      >
>      >      >     Hi Anoop,
>      >      >
>      >      >     I'm willing to consider removing a lot of this but I don't
>      >     understand
>      >      >     what's wrong with Section 1.3, item (3). Say you are a
>      >     provider of SFC
>      >      >     services to many clients and client session are relatively
>      >     long lived
>      >      >     and the services required by a client session can be
>     provided
>      >     through
>      >      >     any one of multiple SFF paths. When a new client
>     session starts,
>      >      >     wouldn't the classified want to have congestion
>     information
>      >     about the
>      >      >     SFF paths in use by existing client sessions when choosing
>      >     the SFF
>      >      >     path to be used by the new session?
>      >      >
>      >      >     Thanks,
>      >      >     Donald
>      >      >     ===============================
>      >      >       Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>      >      >       1424 Pro Shop Court, Davenport, FL 33896 USA
>      >      > [email-masked] <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>      >      >
>      >      >     On Mon, Jan 28, 2019 at 4:23 PM Anoop Ghanwani
>      >      >     <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
>      >      >      >
>      >      >      > Hi Joel,
>      >      >      >
>      >      >      > If that is truly the case, then I think Sections
>     1.3 and 4
>      >     should
>      >      >     be removed.
>      >      >      >
>      >      >      > Otherwise, I myself am not clear what 1.3 and 4 are
>     trying to
>      >      >      > accomplish and therefore would need clarification
>     on that
>      >     from the
>      >      >      > authors.
>      >      >      >
>      >      >      > Thanks,
>      >      >      > Anoop
>      >      >      >
>      >      >      > On Mon, Jan 28, 2019 at 1:20 PM Joel Halpern Direct
>      >      >      > <[email-masked]
>      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      >     <mailto:[email-masked]
>     <mailto:[email-masked]
>     <mailto:[email-masked]>>>>
>      >      >     wrote:
>      >      >      > >
>      >      >      > > I am pretty sure that what is intended is exactly
>     what
>      >     you say you
>      >      >      > > support, namely simple propagation of the information
>      >     for the ECN
>      >      >      > > control loop, not a new loop.
>      >      >      > >
>      >      >      > > Can you suggest additional or modified owrding
>     for the
>      >     document
>      >      >     to help
>      >      >      > > make this clear to readers?
>      >      >      > >
>      >      >      > > Thank you,
>      >      >      > > Joel
>      >      >      > >
>      >      >      > > On 1/28/19 4:18 PM, Anoop Ghanwani wrote:
>      >      >      > > > I read the draft and had a clarification
>     question about
>      >      >     Section 1.3
>      >      >      > > > and Section 4.
>      >      >      > > >
>      >      >      > > > Is the draft suggestion an alternate congestion
>      >     control mechanism
>      >      >      > > > between tunnel ingress and tunnel egress which
>     is working
>      >      >     separately
>      >      >      > > > from end-to-end congestion control that
>     requires ECN?
>      >      >      > > >
>      >      >      > > > If it's just about propagation of bits for the
>     original
>      >      >     feedback loop
>      >      >      > > > (i.e. before the tunnel header is added), I
>     support the
>      >      >     draft.  If
>      >      >      > > > it's attempting to define a new congestion feedback
>      >     loop and
>      >      >      > > > mechanism, I think it may need more discussion.
>      >      >      > > >
>      >      >      > > > Thanks,
>      >      >      > > > Anoop
>      >      >      > > >
>      >      >      > > > On Wed, Jan 23, 2019 at 3:14 PM Joel M. Halpern
>      >      >     <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
>      >      >      > > >>
>      >      >      > > >> While the time for the call has completed, I would
>      >     like to
>      >      >     see the
>      >      >      > > >> current discussion resolve before judging the
>     adoption as
>      >      >     chair (with Jim).
>      >      >      > > >> As a corollary, if anyone who has not spoken
>     up has an
>      >      >     opinion about the
>      >      >      > > >> adoption, it is still VERY helpful if you
>     speak up.
>      >     Please
>      >      >     provide
>      >      >      > > >> motivation for your response.
>      >      >      > > >>
>      >      >      > > >> If things do not resolve clearly on their own,
>     the chairs
>      >      >     will (as is
>      >      >      > > >> required) reach a determination anyway, but WG
>     clarity is
>      >      >     preferred.
>      >      >      > > >>
>      >      >      > > >> Thank you,
>      >      >      > > >> Joel
>      >      >      > > >>
>      >      >      > > >> _______________________________________________
>      >      >      > > >> sfc mailing list
>      >      >      > > >> [email-masked] <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>      >      >      > > >> https://www.ietf.org/mailman/listinfo/sfc
>      >      >      >
>      >      >      > _______________________________________________
>      >      >      > sfc mailing list
>      >      >      > [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked]
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>>
>      >      >      > https://www.ietf.org/mailman/listinfo/sfc
>      >      >
>      >      >