Re: [Pppext] RFC1990 - Sending multiple packet fragments

[James Carlson <james.d.carlson at sun.com>]

Dharanalakota, Divakar (Divakar) writes:
> It was not clear from RFC, whether we can send fragments of multiple
> packets be transmitted over the link interfaces simultaneously.

Yes.  But if reassembly is done correctly, packets are always
reassembled in the original order.

> I mean
> to ask can the reassemble end receive multiple B bit fragments without
> receiving the E bit fragment of first packet. 

In order for that to happen, they'd have to have appropriate sequence
numbers and be on separate links.  It'd be an unusual case.

When arranged in sequence order, the fragments must always be integral
packets (excepting losses, of course).

So, for example, I can fragment four packets like this (the notation
I'm using here for the Name field should be "obvious," though it's not
defined by any standard):

Frag	Name	Description
1	1B-a	First fragment of packet 1
2	1-b	Second fragment of packet 1
3	1E-c	Third and final fragment of packet 1
4	2BE	Only fragment for pFrom pppext-bounces at ietf.org  Fri Jul 11 08:58:54 2008
Return-Path: <pppext-bounces at ietf.org>
X-Original-To: pppext-web-archive at megatron.ietf.org
Delivered-To: ietfarch-pppext-web-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 2344E3A6AD3;
	Fri, 11 Jul 2008 08:58:54 -0700 (PDT)
X-Original-To: pppext at core3.amsl.com
Delivered-To: pppext at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 119603A6AD3
	for <pppext at core3.amsl.com>; Fri, 11 Jul 2008 08:58:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.823
X-Spam-Level: 
X-Spam-Status: No, score=-2.823 tagged_above=-999 required=5 tests=[AWL=0.223, 
	BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id CK6uc+H8plWH for <pppext at core3.amsl.com>;
	Fri, 11 Jul 2008 08:58:52 -0700 (PDT)
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36])
	by core3.amsl.com (Postfix) with ESMTP id 147A93A68C8
	for <pppext at ietf.org>; Fri, 11 Jul 2008 08:58:52 -0700 (PDT)
Received: from dm-east-02.east.sun.com ([129.148.13.5])
	by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id
	m6BFx9AB024924 for <pppext at ietf.org>; Fri, 11 Jul 2008 15:59:09 GMT
Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143])
	by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,
	v2.2) with ESMTP id m6BFx94Z062656
	for <pppext at ietf.org>; Fri, 11 Jul 2008 11:59:09 -0400 (EDT)
Received: from phorcys.east.sun.com (localhost [127.0.0.1])
	by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id
	m6BFePi8029320; Fri, 11 Jul 2008 11:40:25 -0400 (EDT)
Received: (from carlsonj at localhost)
	by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m6BFeN68029317;
	Fri, 11 Jul 2008 11:40:23 -0400 (EDT)
MIME-Version: 1.0
Message-ID: <18551.32487.309046.329289 at gargle.gargle.HOWL>
Date: Fri, 11 Jul 2008 11:40:23 -0400
From: James Carlson <james.d.carlson at sun.com>
To: "Dharanalakota, Divakar (Divakar)" <divakardhar at alcatel-lucent.com>
In-Reply-To: <1A209B72F475B54FB693B7EA2ED2980E81EA9B at INEXC1U02.in.lucent.com>
References: <1A209B72F475B54FB693B7EA2ED2980E81EA9B at INEXC1U02.in.lucent.com>
X-Mailer: VM 7.01 under Emacs 21.3.1
Cc: pppext at ietf.org
Subject: Re: [Pppext] RFC1990 - Sending multiple packet fragments
X-BeenThere: pppext at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PPP Extensions <pppext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pppext>,
	<mailto:pppext-request at ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/pppext>
List-Post: <mailto:pppext at ietf.org>
List-Help: <mailto:pppext-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pppext>,
	<mailto:pppext-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: pppext-bounces at ietf.org
Errors-To: pppext-bounces at ietf.org

Dharanalakota, Divakar (Divakar) writes:
> It was not clear from RFC, whether we can send fragments of multiple
> packets be transmitted over the link interfaces simultaneously.

Yes.  But if reassembly is done correctly, packets are always
reassembled in the original order.

> I mean
> to ask can the reassemble end receive multiple B bit fragments without
> receiving the E bit fragment of first packet. 

In order for that to happen, they'd have to have appropriate sequence
numbers and be on separate links.  It'd be an unusual case.

When arranged in sequence order, the fragments must always be integral
packets (excepting losses, of course).

So, for example, I can fragment four packets like this (the notation
I'm using here for the Name field should be "obvious," though it's not
defined by any standard):

Frag	Name	Description
1	1B-a	First fragment of packet 1
2	1-b	Second fragment of packet 1
3	1E-c	Third and final fragment of packet 1
4	2BE	Only fragmeacket 2
5	3B-a	First fragment of packet 3
6	3E-b	Last fragment of packet 3
7	4B-a	First fragment of packet 4
8	4-b	Second fragment of packet 4
9	4-c	Third fragment of packet 4
10	4E-d	Fourth and final fragment of packet 4

Suppose I have 5 links.  I could schedule these packets:

first	1B-a	1-b	1E-c	2BE	3B-a
second	3E-b	4B-a	4-b	4-c	4E-d

Now suppose that the third link (sending 1E-b and then 4-b) is "slow."
The peer receives 1B-a, 1-b, 2BE, and 3B-a.  It can "reassemble" 2BE,
but it can't use that yet, because it hasn't finished with packet 1
(we're missing fragment 3).

I think this corresponds to the case you're describing.  We have "B"
fragments for packets 1, 2, and 3 at this point, and the "E" fragment
for 2, but we haven't seen the "E" fragment for 1, so we're stuck.

Later, 3E-b, 4B-a, 4-c, and 4E-d come in.  Packet 3 is reassembled, but
we can't deliver it yet.  We now have "B" and "E" fragments for all
but packet 1.

When the delayed 1E-c (fragment 3) finally arrives, you can reassemble
*and* deliver packets 1, 2, and 3.  Then when 4-b (fragment 8) arrives
last, you can reassemble packet 4 and deliver it.

Note that you're not required to encapsulate (or fragment) all packets
when running MP.  It's fine to send plain old IP packets at any time.
They're just not provided any ordering.

Perhaps the right first question here is "what are you trying to do?"

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
_______________________________________________
Pppext mailing list
Pppext at ietf.org
https://www.ietf.org/mailman/listinfo/pppext


nt for packet 2
5	3B-a	First fragment of packet 3
6	3E-b	Last fragment of packet 3
7	4B-a	First fragment of packet 4
8	4-b	Second fragment of packet 4
9	4-c	Third fragment of packet 4
10	4E-d	Fourth and final fragment of packet 4

Suppose I have 5 links.  I could schedule these packets:

first	1B-a	1-b	1E-c	2BE	3B-a
second	3E-b	4B-a	4-b	4-c	4E-d

Now suppose that the third link (sending 1E-b and then 4-b) is "slow."
The peer receives 1B-a, 1-b, 2BE, and 3B-a.  It can "reassemble" 2BE,
but it can't use that yet, because it hasn't finished with packet 1
(we're missing fragment 3).

I think this corresponds to the case you're describing.  We have "B"
fragments for packets 1, 2, and 3 at this point, and the "E" fragment
for 2, but we haven't seen the "E" fragment for 1, so we're stuck.

Later, 3E-b, 4B-a, 4-c, and 4E-d come in.  Packet 3 is reassembled, but
we can't deliver it yet.  We now have "B" and "E" fragments for all
but packet 1.

When the delayed 1E-c (fragment 3) finally arrives, you can reassemble
*and* deliver packets 1, 2, and 3.  Then when 4-b (fragment 8) arrives
last, you can reassemble packet 4 and deliver it.

Note that you're not required to encapsulate (or fragment) all packets
when running MP.  It's fine to send plain old IP packets at any time.
They're just not provided any ordering.

Perhaps the right first question here is "what are you trying to do?"

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
_______________________________________________
Pppext mailing list
Pppext at ietf.org
https://www.ietf.org/mailman/listinfo/pppext