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

"weigengyu" <weigengyu@vip.sina.com> Wed, 21 June 2017 17:06 UTC

Return-Path: <weigengyu@vip.sina.com>
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 43CFD127876 for <lp-wan@ietfa.amsl.com>; Wed, 21 Jun 2017 10:06:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.449
X-Spam-Level:
X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L3=0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439, URIBL_BLOCKED=0.001] autolearn=no 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 YGCg2FeSVgnv for <lp-wan@ietfa.amsl.com>; Wed, 21 Jun 2017 10:06:19 -0700 (PDT)
Received: from smtp-6-47.vip.sina.com.cn (r3-63.sinamail.sina.com.cn [202.108.3.63]) by ietfa.amsl.com (Postfix) with SMTP id E569D128C82 for <lp-wan@ietf.org>; Wed, 21 Jun 2017 10:06:17 -0700 (PDT)
Received: from unknown (HELO WeiGengyuPC)([221.219.54.237]) by vip.sina.com with ESMTP 22 Jun 2017 01:06:11 +0800 (CST)
X-Sender: weigengyu@vip.sina.com
X-Auth-ID: weigengyu@vip.sina.com
X-SMAIL-MID: 746985278672
Message-ID: <F5C7D3EBA1DD42858C339E13F435F7AC@WeiGengyuPC>
From: weigengyu <weigengyu@vip.sina.com>
To: lp-wan@ietf.org, Arun <arun@ackl.io>
References: <59F856E1230C43D5A7CE1018F7C2DCA8@WeiGengyuPC> <912c2aab-a69f-355a-f7c5-730bac5eaafa@ackl.io>
In-Reply-To: <912c2aab-a69f-355a-f7c5-730bac5eaafa@ackl.io>
Date: Thu, 22 Jun 2017 01:06:11 +0800
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="UTF-8"; reply-type="original"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 16.4.3528.331
X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331
Archived-At: <https://mailarchive.ietf.org/arch/msg/lp-wan/0vPB73GU1yef7YfbI71IO7xhe2Y>
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 17:06:22 -0000

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?


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