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

[Anoop Ghanwani <[e-mail]>]

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 <[e-mail]> wrote:

> 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:
> > 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
> >
> > On Thu, Feb 7, 2019 at 9:17 AM Joel M. Halpern <[e-mail]
> > <mailto:[e-mail]>> wrote:
> >
> >     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.
> >      >
> >      > 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 <[e-mail]
> >     <mailto:[e-mail]>
> >      > <mailto:[e-mail] <mailto:[e-mail]>>> 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   [phone] (cell)
> >      >       1424 Pro Shop Court, Davenport, FL 33896 USA
> >      > [e-mail] <mailto:[e-mail]>
> >     <mailto:[e-mail] <mailto:[e-mail]>>
> >      >
> >      >     On Mon, Jan 28, 2019 at 4:23 PM Anoop Ghanwani
> >      >     <[e-mail] <mailto:[e-mail]>
> >     <mailto:[e-mail] <mailto:[e-mail]>>>
> 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
> >      >      > <[e-mail]
> >     <mailto:[e-mail]>
> >     <mailto:[e-mail] <mailto:
> [e-mail]>>>
> >      >     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
> >      >     <[e-mail] <mailto:[e-mail]>
> >     <mailto:[e-mail] <mailto:[e-mail]>>> 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
> >      >      > > >> [e-mail] <mailto:[e-mail]>
> >     <mailto:[e-mail] <mailto:[e-mail]>>
> >      >      > > >> https://www.ietf.org/mailman/listinfo/sfc
> >      >      >
> >      >      > _______________________________________________
> >      >      > sfc mailing list
> >      >      > [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
> >     <mailto:[e-mail]>>
> >      >      > https://www.ietf.org/mailman/listinfo/sfc
> >      >
> >      >
> >      > _______________________________________________
> >      > sfc mailing list
> >      > [e-mail] <mailto:[e-mail]>
> >      > https://www.ietf.org/mailman/listinfo/sfc
> >      >
> >
>