Subject: Re: [pim] I

From: "" <[email-masked]>
Date: Wed, 28 Jan 2004 20:18:56 -0500 (EST)

Thanks Bill and everybody else!
Probably, the same argument holds good for a JOIN/PRUNE
message.It doesn`t have any fragmentation tag?

Arut

 --- On Wed 01/28, William Atwood < [email-masked] > wrote:
From: William Atwood [mailto: [email-masked]]
To: [email-masked]
     Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Date: Wed, 28 Jan 2004 12:47:23 -0500
Subject: Re: [pim] I

What is (perhaps) more to the point---<br><br>If a PIM implementation has something to send, and it sends it to IP as <br>a (say) 30000-byte object, then this will be cut up into (approximately) <br>1500-byte pieces by IP.  These 20 pieces will be sent on the medium.  If <br>_any_one_ of them gets lost, the only possible recovery action is to <br>send the entire 30000 bytes again.<br><br>If a PIM implementation discovers the actual MTU of the path (there is <br>an RFC on how to do this, I don't remember the number), and does its own <br>fragmentation to reduce the size of the objects given to IP so that they <br>match the capabilities of the media on the path, then PIM can recover <br>from individual packets being lost, rather than from 30000-byte objects <br>being lost.<br><br>Two additional points:<br>1) If the probability of losing one fragment is 1%, the probability of <br>losing at least one of 20 fragments is 20%.  These are not very good <br>odds...  It is much better!
  to resend one or two 1500-byte pieces than to <br>resend a 30000-byte piece (which itself would have a 20% probability of <br>being lost).<br>2) For IPv6, fragmentation is (in general) forbidden; the protocol above <br>IP (PIM, in this case) is _required_ to discover the Path MTU, and <br>reduce the size of the objects it sends.  The same should be done for <br>IPv4, as much as possible.<br><br>The overall conclusions are:<br>1) a fragmentation bit is clearly necessary, and<br>2) even if the Path MTU cannot be discovered, no PIM implementation <br>should ever send objects larger than (1500 bytes minus the various <br>protocol headers).<br><br>   Bill Atwood<br><br>girishkg wrote:<br>> Hi All,<br>> I feel fragmentation in PIM is required in the case of sending a JP <br>> packet more than 65535 byte. This can happen when we are sending a (*,G) <br>> Join and S,G,Rpt prunes along with it. The SGRpt state machine expects <br>> all the sources (which need to be pruned for the s!
 hared path )along with <br>> (*,.G) Join in the same JP message.<br>> 
 <br>> I think John Zwiebel meant this in his reply.<br>>  <br>> Thanks<br>> Girish<br>>  <br>> <br>>     -----Original Message-----<br>>     From: [email-masked] [mailto:[email-masked]]On Behalf Of<br>>     Rajamanickam jaganbabu<br>>     Sent: Wednesday, 28 January 2004 5:04 PM<br>>     To: [email-masked]; [email-masked]; [email-masked]<br>>     Cc: [email-masked]; [email-masked] <mailto:[email-masked]><br>>     Subject: Re: [pim] I<br>> <br>>     Hi jzwiebel,<br>>        Aruts is right, IP will take care of fragment/defragment the<br>>     packets, so i don't think we need to take care of<br>>     fragment/defragment in the application level (PIM protocol<br>>     level). But I can't imagine the case where my MTU is more than 65565<br>>     bytes, which IP can't hold. I think it is Ok to remove the<br>>     fragmentation overhead in the PIM protocol.<br>>         I think this will apply for all the fragmentation which PIM is<br>>     supporting, For example !
 even in PIM SM while sending the Register<br>>     message.<br>>      <br>>     Thanx,<br>>     Jags<br>> <br>>     <[email-masked]> wrote:<br>> <br>> <br>>         Hi,<br>> <br>>         IP actually does reassembly before it gives it to PIM and<br>>         PIM receives the complete packet intact.I have seen it work!<br>> <br>>         So, I don`t understand the need for a fragmentation flag!<br>> <br>>         Thanks,<br>>         Arut<br>> <br>> <br>> <br>> <br>>         --- On Tue 01/27, Benjamin Black < [email-masked] > wrote:<br>>         From: Benjamin Black [mailto: [email-masked]]<br>>         To: [email-masked]<br>>         Cc: [email-masked], [email-masked]<br>>         Date: Tue, 27 Jan 2004 19:54:05 -0800<br>>         Subject: Re: [pim] PIM BSM fragmentation<br>> <br>>         put a slightly different way:<br>> <br>>         PIM can generate a message larger than the maximum size for a<br>>         single IP<br>>         packet, so it must be able to re!
 assemble things when a single PIM<br>>         message is fragmented o
ve
 r 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, "" wrote:<br>>          ><br>>          >><br>>          >> I would like to know why fragmentation support (read<br>>         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<br>>         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>> <br>> <br>>         _______________________________________________<br>>         Join Excite! - http://www.excite.com<br>>         T!
 he most personalized portal on the Web!<br>> <br>>         _______________________________________________<br>>         pim mailing list<br>>         [email-masked]<br>>         https://www1.ietf.org/mailman/listinfo/pim<br>> <br>>     Yahoo! India Mobile <http://in.mobile.yahoo.com>: Ringtones,<br>>     Wallpapers, Picture Messages and more. Download now<br>>     <http://in.mobile.yahoo.com>.<br>> <br>> <br>> <br>> ***************************************************************************<br>> This message is proprietary to Future Software Limited (FSL)<br>> and is intended solely for the use of the individual to whom it<br>> is addressed. It may contain privileged or confidential information<br>> and should not be circulated or used for any purpose other than for<br>> what it is intended.<br>> <br>> If you have received this message in error, please notify the<br>> originator immediately. If you are not the intended recipient,<br>> you are notified that you are strictly pr!
 ohibited from using,<br>> copying, altering, or disclosing the content
s of this message.<br>> FSL accepts no responsibility for loss or damage arising from<br>> the use of the information transmitted by this email including<br>> damage from virus.<br>> ***************************************************************************<br><br>-- <br><br>Dr. J.W. Atwood, Eng., Professor  tel:   +1 (514) 848-2424 x3046<br>Department of Computer Science    fax:   +1 (514) 848-2830<br>Concordia University LB927-9      email: [email-masked]<br>1455 de Maisonneuve Blvd. West    http://www.cs.Concordia.ca/~bill<br>Montreal, Quebec Canada H3G 1M8<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