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

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 6 Jun 2003 16:05:52 +0100

Lasse,

My engineering viewpoint is that the number of signalling applications 
and deployment scenarios for which an approach like RSVPoverUDP is 
reasonable is so small as to be not worth the layer model and everything 
else; that's why the WG has adopted a 2205+2961 conceptual starting point
for the NTLP work.

However, I suspect that this (what you propose) is more of a WG charter 
issue than an engineering issue.

cheers,

robert h.

> -----Original Message-----
> From: Lars.Westberg [mailto:[email-masked]]
> Sent: 06 June 2003 16:00
> To: Geib, Ruediger
> Cc: [email-masked]
> Subject: Re: [NSIS] framework: proposal on fragmentation
> 
> 
> The generality of NTLP is a difficutl issue. My point is that I can
> forsee application that is so simple
> that an UDP-style of operation is good enough.
> 
> I do not support the single-mode of operation due to my 
> expectation of a
> complec protocol standard.
> I forseen that we can discuss protocol feature during long 
> time and use
> the generality argument
> for all protocol feature. This will result in a very complex protcol
> when the standaridzation is finished.
> 
> I would recommend that we have two modes of operation in mind:
> RSVPoverSCTP
> RSVPover UDP
> 
> I also recommend to partion the effort for NTLP in these "modes of
> operation"
> 
> If someone want to use high-level of protocol support in NTLP => use
> RSVPoverSCTP.
> If someone want something simple use RSVPoverUDP.
> 
> regards Lasse
> "Geib, Ruediger" wrote:
> 
> > Hi Lasse,
> >
> > | The selection of NTLP-functionality may be coupled to a
> > | certain NSLP-type.
> >
> > This sounds like NSLP specific NTLPs. We don't need a
> > layer split in that case. Like Robert, I don't support
> > this proposal.
> >
> > | In that case you I think that you do not need to have
> > | negotiation between different
> > | NTLP-instances or.. ?
> >
> > Negotiation of options between NTLP-instances isn't
> > desireable from an operators point of view.
> >
> > I understand that at some level within the protocol stack
> > there must be awareness of the path MTU size. We should
> > be careful not to overengineer our solution. If NSIS uses
> > a transport protocol below NTLP which handles the MTU
> > issue, let's make it the default. This would also simplify
> > bundeling within NTLP, wouldn't it?
> >
> > Regards, Rudiger
> > _______________________________________________
> > 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: "Lars.Westberg" <[email-masked]>
Date: Fri, 06 Jun 2003 17:15:50 +0200

Comments below

> else; that's why the WG has adopted a 2205+2961 conceptual starting point

The working group have en started to solve a certain engineering problem e.g
to make a more general solution than RSVP
and makes it simpler.

This working group have started the discussion from another approach:
                Let's include more functionality than RSVP have today.

> issue than an engineering issue.

No, it was included in the problem statement from beginning.

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