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

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 <d3e3e3@gmail.com> 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
>  d3e3e3@gmail.com
>
> On Mon, Jan 28, 2019 at 4:23 PM Anoop Ghanwani <anoop@alumni.duke.edu>
> 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
> > <jmh.direct@joelhalpern.com> 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 <jmh@joelhalpern.com>
> 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
> > > >> sfc@ietf.org
> > > >> https://www.ietf.org/mailman/listinfo/sfc
> >
> > _______________________________________________
> > sfc mailing list
> > sfc@ietf.org
> > https://www.ietf.org/mailman/listinfo/sfc
>