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

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 11 Jun 2003 09:42:33 +0100

dear all,

what i am missing at the moment is a complete picture of how this 'optional
fragmentation scheme' (or schemes?) would really work in practice, including
(as Tom says) what really happens to too-big non-fragmentable messages
(generate
an error and route it back to the originating NSLP? fragment at IP level?)
and
so on.

since this scheme still has the fragmentation functionality in the NTLP, i'm
struggling (i'm trying, but i'm really struggling) to see how it is more
attractive
than just saying 'the NTLP does the fragmentation if it needs to'. my
expectation
would be that all NSLPs would set 'fragmentation allowed' on their messages,

because the NSLP designer can't see any benefit in creating an extra error
case
to handle and doesn't want to invent his own PMTU-like discovery mechanisms.
in 
that case it reduces in practice to the previous case anyway, while
polluting the 
protocol with more error conditions and optional parts.

cheers,

r.

> -----Original Message-----
> From: Thanh Tra LUU [mailto:[email-masked]]
> Sent: 11 June 2003 09:07
> To: Tom Taylor; Georgios Karagiannis
> Cc: [email-masked]
> Subject: Re: [NSIS] framework: proposal on fragmentation
> 
> 
> 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
> 
> 
> 
> ----- Original Message -----
> From: "Tom Taylor" <[email-masked]>
> To: "Georgios Karagiannis" <[email-masked]>
> Cc: "Hancock, Robert" <[email-masked]>; <[email-masked]>
> Sent: Tuesday, June 10, 2003 10:32 PM
> Subject: Re: [NSIS] framework: proposal on fragmentation
> 
> 
> > 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.
> >
> > Georgios Karagiannis wrote:
> >
> > > 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.
> 
> 
> _______________________________________________
> 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: Wed, 11 Jun 2003 11:34:11 +0200

Hi Robert

> an error and route it back to the originating NSLP? fragment at IP level?)

Well, we can define the detailed operation later on.  Now it is important to
mention
that in the default case fragmentation is accomplished by the NTLP.
However, the NSLP instance of NI (NSIS Initiator)  is capable of
deactivating (switching off) the
NTLP fragmentation.

> protocol with more error conditions and optional parts.

If the NSLP instance of NI (NSIS Initiator) NI  needs to use the NTLP
fragmentation then
the "Do fragmentation" bit will be activated. Otherwise, this NSLP instance
will
de-activate (switch off) the "Do Forwarding" bit.

Best regards,
Georgios