Subject: RE: [NSIS] framework: proposal on fragmentation

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 10 Jun 2003 11:46:16 +0100

georgios,

ok, so [i think] you propose that there should be an minimum size NSLP
message that all NTLP instances should be able to transmit (presumably,
regardless of IP version or whatever encapsulation the NTLP itself adds, to
avoid the need to discover things dynamically). anything bigger, the NSLP
itself must fragment before providing it to the NTLP.

would you like to make a suggestion for how big that number should be?

r.

> -----Original Message-----
> From: Georgios Karagiannis [mailto:[email-masked]]
> Sent: 10 June 2003 11:41
> To: Hancock, Robert
> Cc: [email-masked]
> Subject: Re: [NSIS] framework: proposal on fragmentation
> 
> 
> Hi Robert
> 
> The NTLP should be able to transport a message with a
> minimum MTU without  fragmenting it.
> 
> Best Regards,
> Georgios
> 
> 
> 
> 
> 
> ----- Original Message -----
> From: "Hancock, Robert" <[email-masked]>
> To: "'Georgios Karagiannis'" <[email-masked]>; 
> "'Lars.Westberg'"
> <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, June 10, 2003 10:59 AM
> Subject: RE: [NSIS] framework: proposal on fragmentation
> 
> 
> > georgios,
> >
> > in your solution, what happens when an NTLP node gets a 
> too-big message
> > with DF set?
> >
> > r.
> >
> > > -----Original Message-----
> > > From: Georgios Karagiannis [mailto:[email-masked]]
> > > Sent: 10 June 2003 08:50
> > > To: Hancock, Robert; 'Lars.Westberg'
> > > Cc: [email-masked]
> > > Subject: Re: [NSIS] framework: proposal on fragmentation
> > >
> > >
> > > Hi Robert
> > >
> > > What I actually propose is to enhance the flexibility of
> > > the NTLP protocol by giving the ability to a NSLP to
> > > request or not to request the NTLP fragmentation feature.
> > > A possible method of doing this is as follows:
> > >
> > > First of all the NTLP protocol has to use some 
> information, e.g., a
> > > fragmentation bit, to specify that
> > > fragmentation is allowed or not.
> > > Now, if the sender NSLP (NI) informs its NTLP instance to
> > > switch off the
> > > fragmentation, then this NTLP instance
> > > will switch off the fragmentation bit. In this way all the
> > > intermediate NTLP
> > > nodes will know that fragmentation is
> > > not allowed.
> > > Note that in this case NTLP negotiation is not needed!
> > >
> > > Best regards,
> > > Georgios
> > >
> > >
> > > ----- Original Message -----
> > > From: "Hancock, Robert" <[email-masked]>
> > > To: "'Lars.Westberg'" <[email-masked]>
> > > Cc: "Tom Taylor" <[email-masked]>; "Georgios 
> Karagiannis"
> > > <[email-masked]>; <[email-masked]>
> > > Sent: Friday, June 06, 2003 5:42 PM
> > > Subject: RE: [NSIS] framework: proposal on fragmentation
> > >
> > >
> > > > OK - this was option 1 in the original email summary. There
> > > seemed to
> > > > be some resistance to it from several places and a 
> preference to the
> > > > NTLP approach.
> > > >
> > > > What I can imagine you suggesting is: try to get the 
> NSLP to create
> > > messages
> > > > which don't require fragmentation at all (by doing the 
> fragmentation
> > > > itself);
> > > > in the [hopefully rare] cases where something goes wrong,
> > > rely on the IP
> > > > layer to handle it.
> > > >
> > > > That's an approach - I think it's a much more credible 
> approach than
> > > > relying on the NSLP alone, but given the unpleasantness
> > > about doing it
> > > > at either IP or NSLP, I still prefer the NTLP option. 
> Anyway, people
> > > > need to make the argument about which is better and why:
> > > > IP only
> > > > NTLP only
> > > > NSLP only
> > > > IP+NSLP
> > > >
> > > > The other point is: since we are arguing about the
> > > fragmentation aspect
> > > > (rather than the reassembly aspect) .... just how 
> difficult is it to
> > > > chop up a message and put a common header on each part? 
> And how much
> > > > complexity is
> > > > it worth putting in the rest of the network architecture to
> > > save doing it?
> > > >
> > > > cheers,
> > > >
> > > > r.
> > > >
> > > > > -----Original Message-----
> > > > > From: Lars.Westberg [mailto:[email-masked]]
> > > > > Sent: 06 June 2003 16:27
> > > > > To: Hancock, Robert
> > > > > Cc: Tom Taylor; Georgios Karagiannis; [email-masked]
> > > > > Subject: Re: [NSIS] framework: proposal on fragmentation
> > > > >
> > > > >
> > > > > Use IP-fragmentation
> > > > >
> > > > > -lasse
> > > > >
> > > > > "Hancock, Robert" wrote:
> > > > >
> > > > > > aha!
> > > > > >
> > > > > > >
> > > > > > > No, I trying to explain it:
> > > > > > > If you have a network element without knowledge 
> of the NSLP:s
> > > > > > > requirment, the
> > > > > > > default should be to forward it to the next hop 
> without doing
> > > > > > > anything to the
> > > > > > > NSLP-messages.
> > > > > >
> > > > > > *** and what if the message is too big to forward? ***
> > > > > > [which is where we started...]
> > > > > >
> > > > > > >
> > > > > > > regards Lasse
> > > > > > >
> > > > > >
> > > > > > r.
> > > > > >
> > > > > >
> > > > > --------------------------------------------------------------
> > > > > ----------
> > > > > >                           Name: RMRL-Disclaimer.txt
> > > > > >    RMRL-Disclaimer.txt    Type: Plain Text (text/plain)
> > > > > >                       Encoding: 7bit
> > > > >
> > > > _______________________________________________
> > > > nsis mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/nsis
> > > >
> > >
> > _______________________________________________
> > nsis mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/nsis
> >
> 
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 10 Jun 2003 14:25:22 +0200

Hi Robert

> would you like to make a suggestion for how big that number should be?

For example, look into Section 4.2.2.7 of RFC 1812:
    " A common trick used by some implementations of TCP/IP is to
      fragment an IP datagram into IP fragments that are no larger than
      576 bytes when the IP datagram is to travel through a router.
      This is intended to allow the resulting IP fragments to pass the
      rest of the path without further fragmentation. " ,  from RFC1812.

Best regards,
Georgios