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

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 10 Jun 2003 14:51:33 +0100

indeed.

however, even 576 doesn't guarantee that fragmentation won't be needed
(for IPv4 the MTU could be as low as 68), and in any case, you also have to
take out the NTLP encapsulation overhead.

doing unnecessary fragmentation as the NSLP will increase network load,
because you have more more messages. i suppose you could allow the NTLP to bundle
the fragments back together [i did originally consider this option but
discarded it as just too ugly to propose] but the result would still be
bigger than the original could have been, especially if the per-fragment overhead
is large.

i still don't see this as preferable to having the NTLP able to chop up messages.
why is that so hard????

cheers,

r.

> -----Original Message-----
> From: Georgios Karagiannis [mailto:[email-masked]]
> Sent: 10 June 2003 13:25
> To: Hancock, Robert
> Cc: [email-masked]
> Subject: Re: [NSIS] framework: proposal on fragmentation
> 
> 
> Hi Robert
> 
> 
> 
> > 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?
> >
> 
> 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
> 
> >
> > > -----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
> >
> 
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 10 Jun 2003 16:34:51 +0200

Hi Robert

What I actually propose is that when the NSLP is not in favour of NTLP
fragmentation,
then the NTLP should not do fragmentation. If the NSLP activates the
"Do Fragmentation" bit then the NTLP is allowed to do fragmentation.
Otherwise if the NSLP switches off the "Do Fragmentation" bit then the
NTLP will not do fragmentation. Please note that in this situation the NSLP
is
aware of the fragmentation issues and it will either rely on the IP
fragmentation
or try to solve the fragmentation issues by its own.

Best Regards,
Georgios

---

From: Tom Taylor <[email-masked]>
Date: Tue, 10 Jun 2003 16:32:45 -0400

You haven't answered Robert's earlier question: what happens if an intermediate NTLP 
node receives a "don't fragment" message which is too big to pass on.  The obvious 
treatment is to drop the message.  Must the intermediate NTLP node also send a 
message back indicating that the forward message was dropped.

---

From: "Thanh Tra LUU" <[email-masked]>
Date: Wed, 11 Jun 2003 10:06:54 +0200

hi Tom,

I think we can do as you said that a next NTLP uses a notification of  error
(like ICMP). When  a NTLP receives this notification, it notifies NSLP to
reduce the NSLP message's length. So NSLP must be able to fragment its
messages.

Georgios said that NSLP message's length is too small to need fragmenting by
NTLP so this function can be switched off, but how NSLP can know its
message's length is small enough to not need fragmenting ?

I don't think NTLP notifies NSLP about the max length is a good way. Because
it looks like PMTU mechanism, so I think we let NTLP does it all. NTLP can
set the bit "Don't Fragement" or not (for some useful purposes of NTLP), but
it must do it by itself and this is opaque to NSLP.

Nary Tra
ENST, Paris

---

From: "Lars.Westberg" <[email-masked]>
Date: Wed, 11 Jun 2003 10:37:15 +0200

Comment below

> message back indicating that the forward message was dropped.

if NTLP can not forward the meesage, is'nt that a typical error handling condition ?
I forseen that we have to handle many types of errors  in a NTLP-protocol.