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

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 6 Jun 2003 08:49:01 +0100

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 10:08:46 +0200

Hi Robert

> For fragmentation,

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

---

From: "Lars.Westberg" <[email-masked]>
Date: Fri, 06 Jun 2003 16:51:35 +0200

Hi!
Some comments below

> going to have to handle, and an NSLP can't tell downstream NTLP nodes

NSLP will above the NTLP and between those it will be an interface. Can't this
interface include primitves for the NSLP ?
I have difficulties to the issues here.

Are you also saying that we are going into a direction where the only
NTLP-option is RSVPover SCTP ?
Because, you can argue in this way for all protocol features bundling.
fragmentation, reliabillity.....
This will in my opinion limit the usage of NTLP for some applications.
Let's try to specify a one simple operational mode of NTLP-operation where NTLP
can use UDP-like of operation
without all of these features.

My proposal is that we trying to develop two modes of NTLP-operation:

- RSVPover SCTP
- RSVPoverUDP

Regards Lasse

>   ------------------------------------------------------------------------
>                           Name: RMRL-Disclaimer.txt
>    RMRL-Disclaimer.txt    Type: Plain Text (text/plain)
>                       Encoding: 7bit