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

From: "Daniel Warren" <[email-masked]>
Date: Fri, 6 Jun 2003 09:32:06 +0100

I still think we are missing a couple of points here, which Robert has got
close to but hasn't stated explicitly.

Optionality of a feature is only really optional on a node initiating the
feature.  So, ignoring interim nodes for now, even if fragmentation is
optional, any node that can receive NSIS messages has to support re-assembly
because it does not know what form the information it is going to get will
take - it might not be fragmented, but equally it might, and if it is it
will need to be able to reassemble.

So by making fragmentation optional, all you are actually saying is that you
may have nodes where the actually chopping up of the message (which is not a
particularly complex task) is not supported.  The exception to this rule is
a situation where your nodes only use the 'small messages' NSLP type that
Georgios mentioned way back in the thread, and even then that makes that
NSLP pretty inflexible to future growth.

As for if reassembly needs to happen only at the receiver or at every node
in between it depends upon what degree of complexity you want to add to your
route managament.  Consider a path that goes through a number of interim
nodes to get to it's destination.  That will mean a number of interim links
which may have different MTU size per hop.  If you don't want to reassemble
and segment at each node then the node that is doing the fragmentation will
need to know the MTU size for every hop to the destination and fragment to
meet the minimum requirement (otherwise there will be a link where the
packets being sent exceed the MTU size and the packets will get dumped).
One solution to that is to use Roberts proposal of segmenting and
reassembling per hop.  the other would be to allow interim nodes to segment
the segments if it needs to, maybe lower down the stack.

Just some thoughts really.

Dan

-----Original Message-----
From: Georgios Karagiannis [mailto:[email-masked]]
Sent: 06 June 2003 09:09
To: Hancock, Robert
Cc: [email-masked]
Subject: Re: [NSIS] framework: proposal on fragmentation

Hi Robert

> For fragmentation,
> what I find conceptually simplest is mandatory at both ends, or else
> there needs to be a simple answer to the question 'what happens when
> an interior NTLP node (not colocated with the NSLP) is given a message
> it can't forward'.

If an application that uses a NSLP can solve the problem of fragmentation by
its own
then the situation that you describe will not happen. And if this happens
then the application is
aware of that.

Please note that the mandatory support of a feature in the NTLP can affect
the
performance unnecessary.  If this happens to often then there is a chance
that the
NSIS protocol will not be deployed on a large scale.

Please try to be flexible when there is a tradeoff between protocol
perfromance and support
of a long list of mandatory features.

Best regards,
Georgios

----- Original Message -----
From: "Hancock, Robert" <[email-masked]>
To: "'Lars.Westberg'" <[email-masked]>; "Tom Taylor"
<[email-masked]>
Cc: "Georgios Karagiannis" <[email-masked]>; <[email-masked]>
Sent: Friday, June 06, 2003 9:49 AM
Subject: RE: [NSIS] framework: proposal on fragmentation

> dear all,
>
> As a general point, I don't think it is practical to fine tune NTLP
> functionality to NSLP requirements, except by requesting additional
> treatment at the message level. (This sentence may be clarified below.)
>
> The reason is that we have essentially a 'flat' NTLP where an instance
> has to support all signalling application traffic passing through
> that node, even if the node doesn't support that application (FW section
> 3.2.1 if you've forgotten). So an NTLP never knows what NSLPs it is
> going to have to handle, and an NSLP can't tell downstream NTLP nodes
> what to support.
>
> [An alternative architecture, where there was NSLP-sensitive explicit
> next-NTLP-peer discovery and a more session-oriented signalling
association
> between NSLP peers, would enable alternative solutions. But we aren't
> doing that.]
>
> In practice, we have to consider how this works function by function,
> and whether functions can be selectively invoked. In some cases, I think
> we will have functions which are mandatory to implement in the receiver,
> and optional to implement in the sender - this is the case for
> bundling, where the receiver processing is trivial. For fragmentation,
> what I find conceptually simplest is mandatory at both ends, or else
> there needs to be a simple answer to the question 'what happens when
> an interior NTLP node (not colocated with the NSLP) is given a message
> it can't forward'.
>
> cheers,
>
> r.
>
> > -----Original Message-----
> > From: Lars.Westberg [mailto:[email-masked]]
> > Sent: 06 June 2003 08:32
> > To: Tom Taylor
> > Cc: Georgios Karagiannis; Hancock, Robert; [email-masked]
> > Subject: Re: [NSIS] framework: proposal on fragmentation
> >
> >
> > Isn't the functionality in NTLP dependent on NSLP. If a
> > certain NSLP do not want to
> > have
> > bundling and fragementation. Should that not be supported by NTLP ?
> >
> > The selection of NTLP-functionality may be coupled to a
> > certain NSLP-type.
> > In that case you I think that you do not need to have
> > negotiation between different
> > NTLP-instances or.. ?
> >
> >
> > regards Lasse
> > Tom Taylor wrote:
> >
> > > Optionality doesn't work unless it is negotiated, which
> > makes the protocol a lot
> > > more complicated.  I can say my node doesn't support
> > bundling, but what if the
> > > upstream node won't cooperate and sends me a bundled message?
> > >
> > > Georgios Karagiannis wrote:
> > >
> > > > Hi Robert
> > > >
> > > >
> > > >>FWIW I had assumed that reassembly would probably take place at
> > > >>each NSIS-aware node. Apart from anything else, an NSIS-aware node
> > > >>probably couldn't work out what to do with a fragment
> > (either whether
> > > >>to deliver it locally to an application or forward it,
> > and if so even
> > > >>who to forward it to) without doing the reassembly.
> > > >
> > > >
> > > > Yes, but this is additional fragmentation/reassembly
> > functionality that will
> > > > require  additional
> > > > processing, thus the performance behaviour of a node
> > could be affected.
> > > >
> > > > Now if nodes do not support NTLP bundling and if the NSLP
> > is designed in
> > > > such a way that
> > > > NTLP fragmentation is not needed,  then the NTLP
> > reassembly functionality,
> > > > mentioned above, even if it is not needed, will affect
> > negativelly the
> > > > performance behaviour of the node.
> > > >
> > > > What I am actually proposing is that any NSLP should be
> > able to specify if
> > > > NTLP fragmentation/reassembly must be
> > > > supported or not!
> > > > Therefore, I am proposing that the NTLP
> > fragmentation/reassembly feature
> > > > should be optional.
> > > >
> > > > Best regards,
> > > > Georgios
> > > >
> > > > _______________________________________________
> > > > 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: Fri, 6 Jun 2003 11:24:28 +0200

RE: [NSIS] framework: proposal on fragmentationHi Daniel

Sorry, I will repeat this again:

If an application that uses a NSLP can solve the problem of fragmentation by 
its own  then you do not need to activate the fragmentation/reassembly features.
By activate I mean that you initiate these features without really using them.

This can be solved very easily; the sender NSLP, by using the NSLP/NTLP API, 
will inform the NTLP protocol to swicth off the fragmenation option.

Beste Regards,
Georgios

  ----- Original Message ----- 
  From: Daniel Warren 
  To: 'Georgios Karagiannis' ; Hancock, Robert 
  Cc: [email-masked] 
  Sent: Friday, June 06, 2003 10:32 AM
  Subject: RE: [NSIS] framework: proposal on fragmentation

  I still think we are missing a couple of points here, which Robert has got close to but hasn't stated explicitly. 

  Optionality of a feature is only really optional on a node initiating the feature.  So, ignoring interim nodes for now, even if fragmentation is optional, any node that can receive NSIS messages has to support re-assembly because it does not know what form the information it is going to get will take - it might not be fragmented, but equally it might, and if it is it will need to be able to reassemble.

  So by making fragmentation optional, all you are actually saying is that you may have nodes where the actually chopping up of the message (which is not a particularly complex task) is not supported.  The exception to this rule is a situation where your nodes only use the 'small messages' NSLP type that Georgios mentioned way back in the thread, and even then that makes that NSLP pretty inflexible to future growth.

  As for if reassembly needs to happen only at the receiver or at every node in between it depends upon what degree of complexity you want to add to your route managament.  Consider a path that goes through a number of interim nodes to get to it's destination.  That will mean a number of interim links which may have different MTU size per hop.  If you don't want to reassemble and segment at each node then the node that is doing the fragmentation will need to know the MTU size for every hop to the destination and fragment to meet the minimum requirement (otherwise there will be a link where the packets being sent exceed the MTU size and the packets will get dumped).  One solution to that is to use Roberts proposal of segmenting and reassembling per hop.  the other would be to allow interim nodes to segment the segments if it needs to, maybe lower down the stack.

  Dan 

  -----Original Message----- 
  From: Georgios Karagiannis [mailto:[email-masked]] 
  Sent: 06 June 2003 09:09 
  To: Hancock, Robert 
  Cc: [email-masked] 
  Subject: Re: [NSIS] framework: proposal on fragmentation 

  Hi Robert 

  Best regards, 
  Georgios 

  ----- Original Message ----- 
  From: "Hancock, Robert" <[email-masked]> 
  To: "'Lars.Westberg'" <[email-masked]>; "Tom Taylor" 
  <[email-masked]> 
  Cc: "Georgios Karagiannis" <[email-masked]>; <[email-masked]> 
  Sent: Friday, June 06, 2003 9:49 AM 
  Subject: RE: [NSIS] framework: proposal on fragmentation 

  association