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

["Joel M. Halpern" <[e-mail]>]

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]>> 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]>
> 
>     On Mon, Jan 28, 2019 at 4:23 PM Anoop Ghanwani
>     <[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]>>
>     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]>> 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]>
>      > > >> https://www.ietf.org/mailman/listinfo/sfc
>      >
>      > _______________________________________________
>      > sfc mailing list
>      > [e-mail] <mailto:[e-mail]>
>      > https://www.ietf.org/mailman/listinfo/sfc
> 
> 
> _______________________________________________
> sfc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sfc
>