Subject: [pim] I

From: "" <[email-masked]>
Date: Wed, 28 Jan 2004 02:54:05 -0500 (EST)

Hi,

IP actually does reassembly before it gives it to PIM and
PIM receives the complete packet intact.I have seen it work!

So, I don`t understand the need for a fragmentation flag!

Thanks,
Arut

 --- On Tue 01/27, Benjamin Black < [email-masked] > wrote:
From: Benjamin Black [mailto: [email-masked]]
To: [email-masked]
     Cc: [email-masked], [email-masked]
Date: Tue, 27 Jan 2004 19:54:05 -0800
Subject: Re: [pim] PIM BSM fragmentation

put a slightly different way:<br><br>PIM can generate a message larger than the maximum size for a single IP <br>packet, so it must be able to reassemble things when a single PIM <br>message is fragmented over multiple IP packets.<br><br><br>ben<br><br>On Jan 27, 2004, at 5:25 PM, John Zwiebel wrote:<br><br>><br>> On Jan 27, 2004, at 5:16 PM, "" <[email-masked]> wrote:<br>><br>>><br>>> I would like to know why fragmentation support (read fragmentation <br>>> tag) is required at PIM level when IP is already doing it.<br>>><br>><br>> Because if IP does it, it may not include all the source for a given <br>> group within the same<br>> packet.<br>><br>><br>> _______________________________________________<br>> pim mailing list<br>> [email-masked]<br>> https://www1.ietf.org/mailman/listinfo/pim<br>><br>><br><br>

_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!

_______________________________________________
pim mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pim

---

From: Rajamanickam jaganbabu <[email-masked]>
Date: Wed, 28 Jan 2004 11:33:59 +0000 (GMT)

Hi jzwiebel,
   Aruts is right, IP will take care of fragment/defragment the packets, so i don't think we need to take care of fragment/defragment in the application level (PIM protocol level). But I can't imagine the case where my MTU is more than 65565 bytes, which IP can't hold. I think it is Ok to remove the fragmentation overhead in the PIM protocol.
    I think this will apply for all the fragmentation which PIM is supporting, For example even in PIM SM while sending the Register message.
 
Thanx,
Jags

<[email-masked]> wrote:

Hi,

Thanks,
Arut

put a slightly different way:

PIM can generate a message larger than the maximum size for a single IP 
packet, so it must be able to reassemble things when a single PIM 
message is fragmented over multiple IP packets.

ben

On Jan 27, 2004, at 5:25 PM, John Zwiebel wrote:

>
> On Jan 27, 2004, at 5:16 PM, "" wrote:
>
>>
>> I would like to know why fragmentation support (read fragmentation 
>> tag) is required at PIM level when IP is already doing it.
>>
>
> Because if IP does it, it may not include all the source for a given 
> group within the same
> packet.
>
>

_______________________________________________
pim mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pim
Yahoo! India Mobile: Ringtones, Wallpapers, Picture Messages and more.Download now.

---

From: Rajamanickam jaganbabu <[email-masked]>
Date: Wed, 28 Jan 2004 11:33:59 +0000 (GMT)

Hi jzwiebel,
 
Thanx,
Jags

Hi,

Thanks,
Arut

ben

---

From: Rajamanickam jaganbabu <[email-masked]>
Date: Wed, 28 Jan 2004 12:09:25 +0000 (GMT)

Sorry, i have over looked.. It is possible when the MTU is more than 65565 bytes which is very possible in the case of OC interfaces.

Rajamanickam jaganbabu <[email-masked]> wrote:Hi jzwiebel,
   Aruts is right, IP will take care of fragment/defragment the packets, so i don't think we need to take care of fragment/defragment in the application level (PIM protocol level). But I can't imagine the case where my MTU is more than 65565 bytes, which IP can't hold. I think it is Ok to remove the fragmentation overhead in the PIM protocol.
    I think this will apply for all the fragmentation which PIM is supporting, For example even in PIM SM while sending the Register message.
 
Thanx,
Jags

Hi,

Thanks,
Arut

ben

_______________________________________________
pim mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pim
Yahoo! India Mobile: Ringtones, Wallpapers, Picture Messages and more. Download now.

---

From: Rajamanickam jaganbabu <[email-masked]>
Date: Wed, 28 Jan 2004 12:09:25 +0000 (GMT)

Thanx,
Jags

Hi,

Thanks,
Arut

ben

---

From: "girishkg" <[email-masked]>
Date: Wed, 28 Jan 2004 19:44:22 +0530

Hi All,
I feel fragmentation in PIM is required in the case of sending a JP packet
more than 65535 byte. This can happen when we are sending a (*,G) Join and
S,G,Rpt prunes along with it. The SGRpt state machine expects all the
sources (which need to be pruned for the shared path )along with (*,.G) Join
in the same JP message.

I think John Zwiebel meant this in his reply.

Thanks
Girish

  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On Behalf Of
Rajamanickam jaganbabu
  Sent: Wednesday, 28 January 2004 5:04 PM
  To: [email-masked]; [email-masked]; [email-masked]
  Cc: [email-masked]; [email-masked]
  Subject: Re: [pim] I

  Hi jzwiebel,
     Aruts is right, IP will take care of fragment/defragment the packets,
so i don't think we need to take care of fragment/defragment in the
application level (PIM protocol level). But I can't imagine the case where
my MTU is more than 65565 bytes, which IP can't hold. I think it is Ok to
remove the fragmentation overhead in the PIM protocol.
      I think this will apply for all the fragmentation which PIM is
supporting, For example even in PIM SM while sending the Register message.

  Thanx,
  Jags

    Hi,

    Thanks,
    Arut

    ben

    _______________________________________________
    pim mailing list
    [email-masked]
    https://www1.ietf.org/mailman/listinfo/pim
  Yahoo! India Mobile: Ringtones, Wallpapers, Picture Messages and more.
Download now.

***************************************************************************
This message is proprietary to Future Software Limited (FSL)
and is intended solely for the use of the individual to whom it
is addressed. It may contain  privileged or confidential information
and should not be circulated or used for any purpose other than for
what it is intended.

If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message.
FSL accepts no responsibility for loss or damage arising from
the use of the information transmitted by this email including
damage from virus.
***************************************************************************

---

From: "girishkg" <[email-masked]>
Date: Wed, 28 Jan 2004 19:44:22 +0530

Hi All,

Thanks
Girish

  -----Original Message-----

  Hi jzwiebel,

  Thanx,
  Jags

    Hi,

    Thanks,
    Arut

    ben

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 28 Jan 2004 12:32:21 -0500

I would never assume that fragmentation at the IP level is present
on any network - many turn it off - and it also puts you into
the router CPU, so it is much more likely to be dropped.

So application layer fragmentation has a lot of advantages.

It seems odd to have it there and not elsewhere, but I would not
remove it. (It's a little late to change BSR now anyway.)

                                  Regards
                                  Marshall Eubanks

On Wednesday, January 28, 2004, at 06:33 AM, Rajamanickam jaganbabu 
wrote:

> Hi jzwiebel,
>    Aruts is right, IP will take care of fragment/defragment the 
> packets, so i don't think we need to take care of fragment/defragment 
> in the application level (PIM protocol level). But I can't imagine the 
> case where my MTU is more than 65565 bytes, which IP can't hold. I 
> think it is Ok to remove the fragmentation overhead in the PIM 
> protocol.

T.M. Eubanks
e-mail : [email-masked]
http://www.telesuite.com

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 28 Jan 2004 12:32:21 -0500

Regards
                                  Marshall Eubanks

T.M. Eubanks

---

From: William Atwood <[email-masked]>
Date: Wed, 28 Jan 2004 12:47:23 -0500

What is (perhaps) more to the point---

If a PIM implementation has something to send, and it sends it to IP as 
a (say) 30000-byte object, then this will be cut up into (approximately) 
1500-byte pieces by IP.  These 20 pieces will be sent on the medium.  If 
_any_one_ of them gets lost, the only possible recovery action is to 
send the entire 30000 bytes again.

If a PIM implementation discovers the actual MTU of the path (there is 
an RFC on how to do this, I don't remember the number), and does its own 
fragmentation to reduce the size of the objects given to IP so that they 
match the capabilities of the media on the path, then PIM can recover 
from individual packets being lost, rather than from 30000-byte objects 
being lost.

Two additional points:
1) If the probability of losing one fragment is 1%, the probability of 
losing at least one of 20 fragments is 20%.  These are not very good 
odds...  It is much better to resend one or two 1500-byte pieces than to 
resend a 30000-byte piece (which itself would have a 20% probability of 
being lost).
2) For IPv6, fragmentation is (in general) forbidden; the protocol above 
IP (PIM, in this case) is _required_ to discover the Path MTU, and 
reduce the size of the objects it sends.  The same should be done for 
IPv4, as much as possible.

The overall conclusions are:
1) a fragmentation bit is clearly necessary, and
2) even if the Path MTU cannot be discovered, no PIM implementation 
should ever send objects larger than (1500 bytes minus the various 
protocol headers).

   Bill Atwood

girishkg wrote:
> Hi All,
> I feel fragmentation in PIM is required in the case of sending a JP 
> packet more than 65535 byte. This can happen when we are sending a (*,G) 
> Join and S,G,Rpt prunes along with it. The SGRpt state machine expects 
> all the sources (which need to be pruned for the shared path )along with 
> (*,.G) Join in the same JP message.
>  
>     Cc: [email-masked]; [email-masked] <mailto:[email-masked]>
>     Subject: Re: [pim] I
> 
>     Hi jzwiebel,
>     packets, so i don't think we need to take care of
>     fragment/defragment in the application level (PIM protocol
>     level). But I can't imagine the case where my MTU is more than 65565
>     bytes, which IP can't hold. I think it is Ok to remove the
>     fragmentation overhead in the PIM protocol.
>     Yahoo! India Mobile <http://in.mobile.yahoo.com>: Ringtones,
>     Wallpapers, Picture Messages and more. Download now
>     <http://in.mobile.yahoo.com>.
> 
> 
> 

-- 

Dr. J.W. Atwood, Eng., Professor  tel:   +1 (514) 848-2424 x3046
Department of Computer Science    fax:   +1 (514) 848-2830
Concordia University LB927-9      email: [email-masked]
1455 de Maisonneuve Blvd. West    http://www.cs.Concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8

---

From: William Atwood <[email-masked]>
Date: Wed, 28 Jan 2004 12:47:23 -0500

Two additional points:

   Bill Atwood

--