Hi All,

DDK says:
MiniportSendPackets receives an array of packet descriptors arranged
in an order determined by the caller of NdisSendPackets. In __most
cases__, the intermediate driver should maintain this ordering as it
passes an incoming array of packets on to the underlying miniport
driver. An intermediate driver that modifies per-packet information or
OOB data in incoming packets before passing them on to the underlying
driver might reorder an incoming array.


Now what is this "most cases". Is it the case when "intermediate
driver that modifies per-packet information or OOB data in incoming
packets", or any IM driver (i.e. one not modifying the packets) ?


In IM driver, in MiniportSendPackets routine I am cloning the packets
(only TCP/UDP packets) and sending them after some processing. I may
have to send the packets out of order due to the processing needs.
Will everything work fine ? (I was thinking it must work fine, since
IP (on which TCP/UDP rides) is capable of receiving packets out of
order.)

Any comments will be appreciated.

TIA
Abhijit

Re: Out of order packets from NDIS IM by Maxim

Maxim
Wed Jun 23 04:55:33 CDT 2004

NDIS is at LLC layer of OSI model, so, no packet ordering, it is not
relevant for NDIS.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com


"Abhijit" <abhiputs@hotmail.com> wrote in message
news:326d85fd.0406222339.5f9e5da9@posting.google.com...
> Hi All,
>
> DDK says:
> MiniportSendPackets receives an array of packet descriptors arranged
> in an order determined by the caller of NdisSendPackets. In __most
> cases__, the intermediate driver should maintain this ordering as it
> passes an incoming array of packets on to the underlying miniport
> driver. An intermediate driver that modifies per-packet information or
> OOB data in incoming packets before passing them on to the underlying
> driver might reorder an incoming array.
>
>
> Now what is this "most cases". Is it the case when "intermediate
> driver that modifies per-packet information or OOB data in incoming
> packets", or any IM driver (i.e. one not modifying the packets) ?
>
>
> In IM driver, in MiniportSendPackets routine I am cloning the packets
> (only TCP/UDP packets) and sending them after some processing. I may
> have to send the packets out of order due to the processing needs.
> Will everything work fine ? (I was thinking it must work fine, since
> IP (on which TCP/UDP rides) is capable of receiving packets out of
> order.)
>
> Any comments will be appreciated.
>
> TIA
> Abhijit



Re: Out of order packets from NDIS IM by bburgin

bburgin
Wed Jun 23 07:16:57 CDT 2004

------=_NextPart_0001_1E32DF56
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Since you're passed an array, there's nothing to prevent you from changing
the ordering of the packets in the array (or adding/dropping packets in the
array) before you pass it on -- but to do so would be really the exception
rather than the rule and would be really specific to the purpose of your IM
driver. And, I would think, to do so would really confuse the receiving
connection-oriented protocols and wouldn't do too much good to unreliable
protocols.

But, sure, you can change the order.

Bryan S. Burgin
bburgin@microsoft.com

This posting is provided "AS IS" with no warranties, and confers no rights.
------=_NextPart_0001_1E32DF56
Content-Type: text/x-rtf
Content-Transfer-Encoding: 7bit

{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fnil\fprq2\fcharset0 MS Sans Serif;}}
\viewkind4\uc1\pard\f0\fs20 Since you're passed an array, there's nothing to prevent you from changing the ordering of the packets in the array (or adding/dropping packets in the array) before you pass it on -- but to do so would be really the exception rather than the rule and would be really specific to the purpose of your IM driver. And, I would think, to do so would really confuse the receiving connection-oriented protocols and wouldn't do too much good to unreliable protocols.
\par
\par But, sure, you can change the order.
\par
\par Bryan S. Burgin
\par bburgin@microsoft.com
\par
\par This posting is provided "AS IS" with no warranties, and confers no rights.
\par }
------=_NextPart_0001_1E32DF56--


Re: Out of order packets from NDIS IM by Alex

Alex
Wed Jun 23 11:32:48 CDT 2004

TCP should be fine with the reorder, but chanses are you will break some
datagram LAN specific application that will never expect out of order
packets.


"prokash" <prokash@discussions.microsoft.com> wrote in message
news:0EF78F1D-DBF1-40C0-A87C-8BA753DCBACF@microsoft.com...
> How would it confuse connection oriented protocol ??
> I thought tcp will do the sequencing before it gets delivered to upstream
!. And in anycase, lot of traffic should get to tcp in out of order, mostly
because hop-by-hop routing !!!
>
> IIEC, for udp is packet-by-packet ACK, so it is already taken care to be
confused ???
>
> -pro
>
> ""Bryan S. Burgin [MSFT]"" wrote:
>
> > Since you're passed an array, there's nothing to prevent you from
changing
> > the ordering of the packets in the array (or adding/dropping packets in
the
> > array) before you pass it on -- but to do so would be really the
exception
> > rather than the rule and would be really specific to the purpose of your
IM
> > driver. And, I would think, to do so would really confuse the receiving
> > connection-oriented protocols and wouldn't do too much good to
unreliable
> > protocols.
> >
> > But, sure, you can change the order.
> >
> > Bryan S. Burgin
> > bburgin@microsoft.com
> >
> > This posting is provided "AS IS" with no warranties, and confers no
rights



Re: Out of order packets from NDIS IM by Rohit

Rohit
Wed Jun 23 13:55:45 CDT 2004

In "most cases" IM drivers should maintain the order of packets (i.e send in
the same order in which they received it), as it might be important to some
protocols.

other cases not covered under the "most cases" will be when you are
implementing packet prioritization like: implementing 802.1P/Q packet
priority (like QoS etc). In those cases, you need to send higher priority
packets ahead of the lower priority packets.

-Rohit Raina
This posting is provided "AS IS" with no warranties, and confers no rights.


"Abhijit" <abhiputs@hotmail.com> wrote in message
news:326d85fd.0406222339.5f9e5da9@posting.google.com...
> Hi All,
>
> DDK says:
> MiniportSendPackets receives an array of packet descriptors arranged
> in an order determined by the caller of NdisSendPackets. In __most
> cases__, the intermediate driver should maintain this ordering as it
> passes an incoming array of packets on to the underlying miniport
> driver. An intermediate driver that modifies per-packet information or
> OOB data in incoming packets before passing them on to the underlying
> driver might reorder an incoming array.
>
>
> Now what is this "most cases". Is it the case when "intermediate
> driver that modifies per-packet information or OOB data in incoming
> packets", or any IM driver (i.e. one not modifying the packets) ?
>
>
> In IM driver, in MiniportSendPackets routine I am cloning the packets
> (only TCP/UDP packets) and sending them after some processing. I may
> have to send the packets out of order due to the processing needs.
> Will everything work fine ? (I was thinking it must work fine, since
> IP (on which TCP/UDP rides) is capable of receiving packets out of
> order.)
>
> Any comments will be appreciated.
>
> TIA
> Abhijit



Re: Out of order packets from NDIS IM by bburgin

bburgin
Wed Jun 23 19:57:21 CDT 2004

------=_NextPart_0001_20EB0A54
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

I shouldn't have said "confuse", but rather, "work harder" as it would
force retries and sequencing for a particular data scheme. As Rohit
pointed out, there are some reasons you might based on your driver's
purpose. But in general you should keep the integrity of the order.

Bryan S. Burgin
bburgin@microsoft.com

This posting is provided "AS IS" with no warranties, and confers no rights.
------=_NextPart_0001_20EB0A54
Content-Type: text/x-rtf
Content-Transfer-Encoding: 7bit

{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fnil\fprq2\fcharset0 MS Sans Serif;}}
\viewkind4\uc1\pard\f0\fs20 I shouldn't have said "confuse", but rather, "work harder" as it would force retries and sequencing for a particular data scheme. As Rohit pointed out, there are some reasons you might based on your driver's purpose. But in general you should keep the integrity of the order.
\par
\par Bryan S. Burgin
\par bburgin@microsoft.com
\par
\par This posting is provided "AS IS" with no warranties, and confers no rights.
\par
\par }
------=_NextPart_0001_20EB0A54--


Re: Out of order packets from NDIS IM by Stephan

Stephan
Tue Jun 29 14:18:50 CDT 2004

Jumping into this discussion tardily, I agree with Rohit that packet
prioritizing will of course change packet order (see e.g.
NDIS_PACKET_8021Q_INFO and
http://msdn.microsoft.com/library/en-us/network/hh/network/204_802p_716fe071-3662-47f3-bacd-5eb6004a88c7.xml.asp).

However, one should *never* change the order of packets that have the
same priority. It used to be a known problem (back in these old days)
that NetBEUI crashes when the order of packets gets changed. Although
this was clearly an implementation bug, performance will probably
suffer e.g. for most TCP implementations. (It is IMHO a fairytale that
most current TCP implementations can cope with misordered packets.)

Also, why would one ever need to change the order? Is that something
like when one wants to spend one's change first before the bills?

Stephan
---
On Wed, 23 Jun 2004 11:55:45 -0700, "Rohit Raina"
<RohitR@online.microsoft.com> wrote:

>In "most cases" IM drivers should maintain the order of packets (i.e send in
>the same order in which they received it), as it might be important to some
>protocols.
>
>other cases not covered under the "most cases" will be when you are
>implementing packet prioritization like: implementing 802.1P/Q packet
>priority (like QoS etc). In those cases, you need to send higher priority
>packets ahead of the lower priority packets.
>
>-Rohit Raina
>This posting is provided "AS IS" with no warranties, and confers no rights.
>
>
>"Abhijit" <abhiputs@hotmail.com> wrote in message
>news:326d85fd.0406222339.5f9e5da9@posting.google.com...
>> Hi All,
>>
>> DDK says:
>> MiniportSendPackets receives an array of packet descriptors arranged
>> in an order determined by the caller of NdisSendPackets. In __most
>> cases__, the intermediate driver should maintain this ordering as it
>> passes an incoming array of packets on to the underlying miniport
>> driver. An intermediate driver that modifies per-packet information or
>> OOB data in incoming packets before passing them on to the underlying
>> driver might reorder an incoming array.
>>
>>
>> Now what is this "most cases". Is it the case when "intermediate
>> driver that modifies per-packet information or OOB data in incoming
>> packets", or any IM driver (i.e. one not modifying the packets) ?
>>
>>
>> In IM driver, in MiniportSendPackets routine I am cloning the packets
>> (only TCP/UDP packets) and sending them after some processing. I may
>> have to send the packets out of order due to the processing needs.
>> Will everything work fine ? (I was thinking it must work fine, since
>> IP (on which TCP/UDP rides) is capable of receiving packets out of
>> order.)
>>
>> Any comments will be appreciated.
>>
>> TIA
>> Abhijit