Re: [Manet-dt] SMF: Usage of IPv4 Identification field

Brian Adamson <adamson@itd.nrl.navy.mil> Fri, 20 April 2007 13:11 UTC

Return-path: <manet-dt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HestH-0000b1-EB; Fri, 20 Apr 2007 09:11:07 -0400
Received: from manet-dt by megatron.ietf.org with local (Exim 4.43) id 1HestF-0000XV-Ri for manet-dt-confirm+ok@megatron.ietf.org; Fri, 20 Apr 2007 09:11:05 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HestF-0000XI-Gr for manet-dt@ietf.org; Fri, 20 Apr 2007 09:11:05 -0400
Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HestD-0001XT-2t for manet-dt@ietf.org; Fri, 20 Apr 2007 09:11:05 -0400
Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.6+Sun/8.12.8) with SMTP id l3KDAxvX026514; Fri, 20 Apr 2007 09:11:02 -0400 (EDT)
Received: from [132.250.92.151] ([132.250.92.151]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.12.43) with SMTP id M2007042009110132728 ; Fri, 20 Apr 2007 09:11:01 -0400
Mime-Version: 1.0
Message-Id: <p06240801c24e67f84b0c@[132.250.92.151]>
In-Reply-To: <001d01c77daf$290af040$0202a8c0@Teco>
References: <001d01c77daf$290af040$0202a8c0@Teco>
Date: Fri, 20 Apr 2007 09:10:59 -0400
To: Teco Boot <teco@inf-net.nl>, manet-dt@ietf.org
From: Brian Adamson <adamson@itd.nrl.navy.mil>
Subject: Re: [Manet-dt] SMF: Usage of IPv4 Identification field
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Cc:
X-BeenThere: manet-dt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: MANET Design Team <manet-dt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/manet-dt>, <mailto:manet-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/manet-dt>
List-Post: <mailto:manet-dt@ietf.org>
List-Help: <mailto:manet-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/manet-dt>, <mailto:manet-dt-request@ietf.org?subject=subscribe>
Errors-To: manet-dt-bounces@ietf.org

I don't think the rules have been well-followed by some, most or 
maybe any operating systems.  I think most (Win32, BSD, while Linux 
seems to exhibit bit different behaviors) simply increment the ID 
field for each packet sent regardless of the destination ... This 
probably results in compliance with RFC 791, but is increasingly 
problematic for multi-homed cases or when there is great disparity of 
transmission rate for different flows that end up taking different 
paths through the network.  I think it is quite likely if one has a 
high bandwidth interface and another lower bandwidth (and perhaps 
long delay such as cellular, SATCOM) interface that a flow on the 
high speed interface could wrap the 16-bit sequence space in parallel 
with some low duty cycle flow on the slow interface.

In the age of higher speeds and multi-homing, etc ... I think it is 
worthwhile to clarify that sequence space SHOULD be managed at least 
on a per <source:destination> tuple basis


I suppose the <protocol> could be added, but that doesn't typically 
have bearing on the path the data takes ... although I guess it could 
for forms of policy-based routing, etc ....

The main thing is that it would be nice for operating systems to have 
some consistent behavior here ... in lieu of this, we made a specific 
recommendation to support SMF needs.

I am curious as to what others think here ...

At 11:36 AM +0200 4/13/07, Teco Boot wrote:
>The SMF ID deviates from RFC791 for the Identification field.
>
>791: "The originating protocol module of an internet datagram sets the
>identification field to a value that must be unique for that
>source-destination pair and protocol"
>
>SMF: "In the case that resequencing is deemed necessary, it is RECOMMENDED
>that sequence numbering be applied such that a different sequence number
>space per <sourceAddress::destinationAddress> duple be used"
>
>The difference is the protocol field. I see two options, modify SMF or add
>text clarifying the deviation and analyze for consequences. Or are the rules
>for Identification changed since 791?
>
>Teco
>
>
>_______________________________________________
>Manet-dt mailing list
>Manet-dt@ietf.org
>https://www1.ietf.org/mailman/listinfo/manet-dt


-- 
Brian
__________________________________
Brian Adamson
<mailto:adamson@itd.nrl.navy.mil>


_______________________________________________
Manet-dt mailing list
Manet-dt@ietf.org
https://www1.ietf.org/mailman/listinfo/manet-dt