Re: [6lo] Mirja Kühlewind's Discuss on draft-ietf-6lo-fragment-recovery-13: (with DISCUSS and COMMENT)

Suresh Krishnan <suresh.krishnan@gmail.com> Mon, 23 March 2020 22:03 UTC

Return-Path: <suresh.krishnan@gmail.com>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 201433A0FCC; Mon, 23 Mar 2020 15:03:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 yuBtI32FVw7d; Mon, 23 Mar 2020 15:03:19 -0700 (PDT)
Received: from mail-qv1-xf29.google.com (mail-qv1-xf29.google.com [IPv6:2607:f8b0:4864:20::f29]) (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 603E03A0FC9; Mon, 23 Mar 2020 15:03:13 -0700 (PDT)
Received: by mail-qv1-xf29.google.com with SMTP id o18so8169704qvf.1; Mon, 23 Mar 2020 15:03:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NM2sXV9zmVXckLOpcDKk9Ety+BdBmdU88N0cNWjQ3Go=; b=VbRJ0H5Ouy6NRfVpRXq7k/mFl+pFokZMEIehvMHNBz5H4jrYTVZX9JUF/97P/33wnq loZsQpQQPd44Tp0K+7isq7JM+6LCykRsDtWR85IU54ns0gzoANrJeGGo74ATOfnYpmny iZcBqCiPFGFpwsuVKdOZcTFAYZwk/5EDvA4nK8Kfhjp3WTCZHWIdHZsvbkj5It+EbOeO VU2fXofQYtQlVvzgU8h0bGuC5oWFN34TzrNOZqhP8Dn2XkaIjyh/iaSDOM6vfV0mEG+G vdCRMYt5BD/4Xuav/yYbR4zfW+bR4cOs7bn3MAR0zLYtxL7XhxdSE2dpV/8SSacrlYb1 g07Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NM2sXV9zmVXckLOpcDKk9Ety+BdBmdU88N0cNWjQ3Go=; b=IH0NJSWXGgdKGA67mrbzqxFD96eJyZeU8wt7/tPh8JDG2SWtvyWgSOqMTfykLRs11w UpTq5ipmhSbsbWyztiDVo96nVpFC1eQy0mBVddMR9LzaSOQmYQ00SYdqkqJ2n38PhgUs orCzUtqQ2DWaSddnwhcv10btLyK+ZTtUKzVHf5JbTMMc3gzU3c0cznIIlAwLil2xCBRG TyDpA3verkGY3I0wnQoAP91rlkyTvzucEkgBU/fBdV9NO6oK2Wg0yLuxwpD8dB7oeov3 zJxEKY8GcIyYRa7VaBfgu0AZuM0hvB8N1P0zdBXC1FXKTc/wBcvfiHmEboF4vJSF523S MWsw==
X-Gm-Message-State: ANhLgQ3Zw4ptQJojWM7aYi2KyFz2vHaYQBVS77xqiQvD+jSEXzHX3eJ1 Ec26uB5dmeyx+XONJh43BfUzXHl04lg=
X-Google-Smtp-Source: ADFU+vtamnxQKp1xR700vJvz12jWPO8f3dVikVMZw5eKVR33+8AKOsYlrM8ABtH3oLbiK0FVJMRspA==
X-Received: by 2002:a0c:e886:: with SMTP id b6mr22628441qvo.31.1585000992238; Mon, 23 Mar 2020 15:03:12 -0700 (PDT)
Received: from [10.0.0.20] (45-19-110-76.lightspeed.tukrga.sbcglobal.net. [45.19.110.76]) by smtp.gmail.com with ESMTPSA id y21sm11367102qka.37.2020.03.23.15.03.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Mar 2020 15:03:11 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
From: Suresh Krishnan <suresh.krishnan@gmail.com>
In-Reply-To: <MN2PR11MB356506F69A0CC8DD2E6EDF3CD8F00@MN2PR11MB3565.namprd11.prod.outlook.com>
Date: Mon, 23 Mar 2020 18:03:10 -0400
Cc: Mirja Kuehlewind <ietf@kuehlewind.net>, "6lo-chairs@ietf.org" <6lo-chairs@ietf.org>, The IESG <iesg@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>, "draft-ietf-6lo-fragment-recovery@ietf.org" <draft-ietf-6lo-fragment-recovery@ietf.org>, Carles Gomez <carlesgo@entel.upc.edu>, Martin Duke <martin.h.duke@gmail.com>, Benjamin Kaduk <kaduk@mit.edu>
Content-Transfer-Encoding: quoted-printable
Message-Id: <12F557A0-8871-49B9-9192-FFF4B1E3C693@gmail.com>
References: <158212059997.17584.9409485384556514167.idtracker@ietfa.amsl.com> <MN2PR11MB356540107CC4FC7F9CB9F412D8E30@MN2PR11MB3565.namprd11.prod.outlook.com> <7D77F80D-9D2C-4AF7-AB7E-4EDF58A9258A@kuehlewind.net> <MN2PR11MB3565C75A4707268047E1F90ED8F40@MN2PR11MB3565.namprd11.prod.outlook.com> <9823A19B-CA7D-47D1-92FE-8AA436240BD4@kuehlewind.net> <C3771F28-264D-4D0D-9864-D40711EBA0FD@cisco.com> <D3F4ECB5-3E1D-48EF-83D9-71F3F14629C4@kuehlewind.net> <MN2PR11MB3565B3E9A05CF5D10D125407D8F50@MN2PR11MB3565.namprd11.prod.outlook.com> <14C773BF-09B3-43A9-893C-8CC8A03E7159@kuehlewind.net> <MN2PR11MB35651B894A5B29455B4033A8D8F50@MN2PR11MB3565.namprd11.prod.outlook.com> <69FA92C7-0F93-4A20-B2C8-D3799375C2A0@kuehlewind.net> <MN2PR11MB356506F69A0CC8DD2E6EDF3CD8F00@MN2PR11MB3565.namprd11.prod.outlook.com>
To: "Pascal Thubert (pthubert)" <pthubert=40cisco.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3608.40.2.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/7DQMiUIQO3TFpL7iDCUCH1eOi1I>
Subject: Re: [6lo] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-6?= =?utf-8?q?lo-fragment-recovery-13=3A_=28with_DISCUSS_and_COMMENT=29?=
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Mar 2020 22:03:44 -0000

Hi Pascal,
  I went through the latest rev and found an off-by-one error on the Fragment size.

* Section 5.1.

   Fragment_Size:  10-bit unsigned integer; the size of this fragment in
      a unit that depends on the Link-Layer technology.  Unless
      overridden by a more specific specification, that unit is the
      byte, which allows fragments up to 1024 bytes.

Shouldn’t this be fragments upto *1023* bytes instead of 1024 bytes?

Thanks
Suresh

> On Mar 23, 2020, at 9:54 AM, Pascal Thubert (pthubert) <pthubert=40cisco.com@dmarc.ietf.org> wrote:
> 
> Hello Again Mirja : )
> 
> 
>> Thanks for this additional text. I just cleared my discuss.
> Very cool; again and again, many thanks for your deep reviews.
> 
>> 
>> A couple of nits you/Suresh maybe want to add as RFC editor note:
> 
> 
> Happy to republish:           https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-fragment-recovery-21 
> 
>> 
>> OLD
>> Note that the action upon detecting a congestion only applies till the end of
>> the datagram 
>> NEW Note that the action upon detecting congestion only
>> applies till the end of the datagram.
>> MAYBE EVEN
>> Note that any action that has been performed upon detection of congestion
>> only applies for the transmission of one datagram
> 
> Picked the latter
> 
>> 
>> OLD
>> an inter-frame gap can be as a flow control or a congestion control measure
>> NEW The inter-frame gap can be used as a flow control or a congestion
>> control measure
> 
> done
> 
>> OLD
>> a conservative Window_Size of, say, 3, will be the gating factor that starves
>> the sender 
>> MAYBE a conservative Window_Size of, say, 3, will be the gating
>> factor that limits the transmission rate of the sender
>> 
> 
> 
> Again and again, many thanks;
> all the best with the IAB,
> 
> Pascal
>