Re: [lp-wan] Fw: re-order header field request

அருண்பிரபு (arunprabhu) <arun@ackl.io> Wed, 21 June 2017 19:27 UTC

Return-Path: <arun@ackl.io>
X-Original-To: lp-wan@ietfa.amsl.com
Delivered-To: lp-wan@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B67221241FC for <lp-wan@ietfa.amsl.com>; Wed, 21 Jun 2017 12:27:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.118
X-Spam-Level:
X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, 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 oSSBrlREfgQL for <lp-wan@ietfa.amsl.com>; Wed, 21 Jun 2017 12:27:12 -0700 (PDT)
Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [217.70.183.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CFC8128CDB for <lp-wan@ietf.org>; Wed, 21 Jun 2017 12:27:11 -0700 (PDT)
Received: from mfilter11-d.gandi.net (mfilter11-d.gandi.net [217.70.178.131]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id 8F99BC5A5C for <lp-wan@ietf.org>; Wed, 21 Jun 2017 21:27:10 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter11-d.gandi.net
Received: from relay2-d.mail.gandi.net ([IPv6:::ffff:217.70.183.194]) by mfilter11-d.gandi.net (mfilter11-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id l3uCADBBwb0H for <lp-wan@ietf.org>; Wed, 21 Jun 2017 21:27:08 +0200 (CEST)
X-Originating-IP: 209.85.223.177
Received: from mail-io0-f177.google.com (mail-io0-f177.google.com [209.85.223.177]) (Authenticated sender: arun@acklio.com) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 81D8AC5A67 for <lp-wan@ietf.org>; Wed, 21 Jun 2017 21:27:06 +0200 (CEST)
Received: by mail-io0-f177.google.com with SMTP id t87so9941637ioe.0 for <lp-wan@ietf.org>; Wed, 21 Jun 2017 12:27:06 -0700 (PDT)
X-Gm-Message-State: AKS2vOydMxVx6EsuL8lSR0O4HLVlSflg5a7wwYEdQq/PVWIqVQrrZ+NN Z2IE0SdlsSRw55UHZ5W8wRv/PARt0Q==
X-Received: by 10.107.173.221 with SMTP id m90mr38309900ioo.152.1498073225755; Wed, 21 Jun 2017 12:27:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.36.36.6 with HTTP; Wed, 21 Jun 2017 12:27:05 -0700 (PDT)
Received: by 10.36.36.6 with HTTP; Wed, 21 Jun 2017 12:27:05 -0700 (PDT)
In-Reply-To: <F5C7D3EBA1DD42858C339E13F435F7AC@WeiGengyuPC>
References: <59F856E1230C43D5A7CE1018F7C2DCA8@WeiGengyuPC> <912c2aab-a69f-355a-f7c5-730bac5eaafa@ackl.io> <F5C7D3EBA1DD42858C339E13F435F7AC@WeiGengyuPC>
From: "அருண்பிரபு (arunprabhu)" <arun@ackl.io>
Date: Wed, 21 Jun 2017 21:27:05 +0200
X-Gmail-Original-Message-ID: <CAEW-XCC6WWU5Y0cG22c7OQriF3_2i2+MZe2j6xgpP4Rs5mnupw@mail.gmail.com>
Message-ID: <CAEW-XCC6WWU5Y0cG22c7OQriF3_2i2+MZe2j6xgpP4Rs5mnupw@mail.gmail.com>
To: weigengyu <weigengyu@vip.sina.com>
Cc: lp-wan@ietf.org
Content-Type: multipart/alternative; boundary="001a11449aa6780d6305527d5aeb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lp-wan/_7AkftLqiVeg57L10YGCf7TJW8c>
Subject: Re: [lp-wan] Fw: re-order header field request
X-BeenThere: lp-wan@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" <lp-wan.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lp-wan>, <mailto:lp-wan-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lp-wan/>
List-Post: <mailto:lp-wan@ietf.org>
List-Help: <mailto:lp-wan-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lp-wan>, <mailto:lp-wan-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Jun 2017 19:27:16 -0000

Hi Gengyu,

On Jun 21, 2017 7:06 PM, "weigengyu" <weigengyu@vip.sina.com> wrote:


Hi Arun,


BigPacket -> SCHC-> if size > MTU ? -> then fragment; else no fragment.
> In such cases, RuleID serves the purpose to identify if the incoming
> packet is a fragmented packet
>

If a packet is fragmented, each fragment contain both Rule ID and Dtag as
the draft defined.
But, the receiver can know which Rule ID is used by the Dtag in the
succesive fragments even in which Rule ID in not existed.


or if it's just came out of SCHC.
>

If a packet is not fragmented, there is a Rule ID as a indication.
Is there a Dtag?

There is no Dtag  in this case.



Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
-----原始邮件----- From: Arun
Sent: Wednesday, June 21, 2017 11:52 PM
To: lp-wan@ietf.org

Subject: Re: [lp-wan] Fw: re-order header field request

Hi Gengyu,
The flow shall be;

BigPacket -> SCHC-> if size > MTU ? -> then fragment; else no fragment.

In such cases, RuleID serves the purpose to identify if the incoming
packet is a fragmented packet or if it's just came out of SCHC. If we
are sure that all the packets received will be fragmented then it makes
sense to send ruleID at the beginning.

hope that helps,
Arun


On 21/06/2017 17:10, weigengyu wrote:

>
>
>
> Hi Carles,
>
> Suppose that one packet is partitioned into two fragments.
>
> Because the Dtag indicates two fragments belonged to one packet,
> the Rule ID in the second fragment is repeated, or redundent, isn't it?
>
> If the Rule ID is not exist in the second fragment,
> the receiver can process it according to the Dtag which is the same in
> two fragments.
> Is there any confusions at the receiver side?
>
> Regards,
>
> Gengyu WEI
> Network Technology Center
> School of Computer
> Beijing University of Posts and Telecommunications
> -----原始邮件----- From: Carles Gomez Montenegro
> Sent: Wednesday, June 21, 2017 2:07 PM
> To: weigengyu
> Subject: Re: [lp-wan] Fw: re-order header field request
>
>
> Hi Gengyu,
>
> Why each successive fragment must contain a Rule ID?
>> It is known that the DTag is used as an indication of fragments belonged
>> to
>> the same IPv6 packet.
>> A Rule ID in the first fragement can be passed to the receiver how to do
>> HC
>> compression,
>> but the successive fragments containing a Rule ID just send a redundent
>> information to the receiver.
>> Right?
>>
>
> The Rule ID is needed to provide a receiver with information on what type
> of content is being carried (and how it has to be handled). Note that not
> all IPv6 packets will require fragmentation, and then losses may happen,
> also non-fragmented packets may be interleaved with fragments, etc.
>
> Cheers,
>
> Carles
>
>
> Regards,
>>
>> Gengyu WEI
>> Network Technology Center
>> School of Computer
>> Beijing University of Posts and Telecommunications
>>
>
>
> _______________________________________________
> lp-wan mailing list
> lp-wan@ietf.org
> https://www.ietf.org/mailman/listinfo/lp-wan
>








_______________________________________________
lp-wan mailing list
lp-wan@ietf.org
https://www.ietf.org/mailman/listinfo/lp-wan

_______________________________________________
lp-wan mailing list
lp-wan@ietf.org
https://www.ietf.org/mailman/listinfo/lp-wan