Re: RFC1990 - Sending multiple packet fragments
Dharanalakota, Divakar (Divakar <divakardhar <at> alcatel-lucent.com>
2008-07-14 06:27:44 GMT
James,
Thanks for the detailed explanation. My aim is to do the interleaving of
the voice packets along with the data packets and provide smaller
serialization delay for the voice packets. I have some more questions
from your explanation.
Can the sequence number have holes while sender is transmitting the
packets. W.r.t the example, lets say 1B-a is having sequence number of
10, does 2BE need to have 13 only or can it start from some other number
like 20. This means to say there is a jump in the sequence number from
13 to 20 while transmitting the packets. Here there is jump across the
packets only, but sequence number is contiguous for all the fragments of
a single packet.
-Divakar
-----Original Message-----
From: James Carlson [mailto:james.d.carlson <at> sun.com]
Sent: Friday, July 11, 2008 9:10 PM
To: Dharanalakota, Divakar (Divakar)
Cc: pppext <at> ietf.org
Subject: Re: [Pppext] RFC1990 - Sending multiple packet fragments
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 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
RSS Feed