IETF Logo Mail Archive

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

Anoop Ghanwani <anoop@alumni.duke.edu> Mon, 28 January 2019 21:23 UTC

Return-Path: <ghanwani@gmail.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE14C12E7C1 for <sfc@ietfa.amsl.com>; Mon, 28 Jan 2019 13:23:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c10rlbmbfdkL for <sfc@ietfa.amsl.com>; Mon, 28 Jan 2019 13:23:13 -0800 (PST)
Received: from mail-vs1-f43.google.com (mail-vs1-f43.google.com [209.85.217.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97E59131204 for <sfc@ietf.org>; Mon, 28 Jan 2019 13:23:13 -0800 (PST)
Received: by mail-vs1-f43.google.com with SMTP id v205so10685803vsc.3 for <sfc@ietf.org>; Mon, 28 Jan 2019 13:23:13 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7oAnOtzINrceSqvDNZqDBfpW9nTXKyItBs/MSoBOUEs=; b=dOEd83kkNwyO5/bCjnAwFUE3teLv2rdjGJA9jflHpkUWJ55RAkgI24PM5btCOcqmIV BCRtFGYb4F9rAMi/6k4VcjzTZ5iXUfCvh1WvYhvvpTDXme2kkgDQC1ONzoMdbSIVwLuj wjpR30JmmdT9x/6AJ63/PtTvoL0jjlIKLSv8ZhZEZ5aICQVYfNacQyyKixOlKuJMLaQl PuuvciLGI8kl8Qph958w0bXQYcnCismvbx5qGnSBR48bj5NzHOMeAqT6f7w/TSnRdgUJ FBsicIuaKT5xhYalEF9YJYtaIadr8djRSFmJZSjgkL10yy56Tx4Z1xL7udn+xxKJFyg9 gDEA==
X-Gm-Message-State: AJcUukdy2MzJTIgMj/i94FDieJw5PFEk1yI14vGQ8RGHFnnrDa3hbkq1 C0BBoXpJMKcrXJQxkAcx0rCzEYYUZ/gNlpchB9w=
X-Google-Smtp-Source: ALg8bN77vX3i+kmSvZnXPweIJONSepmoEd9YuRzCn12Bt3i57jH9SYCuLHsQwCk3d3QKaIacK+m22eJxMhXY+x6P+wE=
X-Received: by 2002:a67:4bcd:: with SMTP id f74mr9795225vsg.60.1548710592596; Mon, 28 Jan 2019 13:23:12 -0800 (PST)
MIME-Version: 1.0
References: <ddd62bd9-cf50-afb4-69a9-5a16c192cd00@joelhalpern.com> <CA+-tSzzWZM7S-KMkrXim8ZA-n1Pu7Xqp+QfahkjRet6PRCnWqA@mail.gmail.com> <2a7e8ef0-4528-663e-89f6-51a0ea729013@joelhalpern.com>
In-Reply-To: <2a7e8ef0-4528-663e-89f6-51a0ea729013@joelhalpern.com>
From: Anoop Ghanwani <anoop@alumni.duke.edu>
Date: Mon, 28 Jan 2019 13:23:00 -0800
Message-ID: <CA+-tSzwajc6Q0Z+Rk1nsUuhbVAbxR9O+D+cTrB4OT=byRdi_=g@mail.gmail.com>
To: Joel Halpern Direct <jmh.direct@joelhalpern.com>
Cc: "sfc@ietf.org" <sfc@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/nEkVASUQMFmp8Ik7fzX914zK-0o>
Subject: Re: [sfc] Regarding draft-eastlake-sfc-nsh-ecn-support adoption call
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Jan 2019 21:23:16 -0000

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

v2.23.0 | Report a Bug | By Email