Subject: RE: [NSIS] Re: What is the goal of the analysis draft?

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Tue, 3 Dec 2002 16:51:07 +0100

Hi

We could always use experience from other (than RSVP)
existing work, even if it is not listed (referenced) in the 
analysis draft!
Just focus and analyze the positive features and the 
main drawbacks of RSVP, since this is one of the main 
goals of the updated NSIS WG charter!

We should not be interested at the moment on other protocols.

Best regards,
Georgios 

-----Original Message-----
From: Jukka MJ Manner [mailto:[email-masked]]
Sent: dinsdag 3 december 2002 16:44
To: [email-masked]
Subject: RE: [NSIS] Re: What is the goal of the analysis draft?

My point is that we are not choosing anything in this document. It would
be used as a reference of existing work (design decisions people have
done) when designing ourselves the NTLP or RSVPv2 or whatever that is.

The evaluation parts of the document need to be agreed on the list, of 
course.

Jim

On Tue, 3 Dec 2002, Georgios Karagiannis (ELN) wrote:

> Hi
> 
> Yes, but then you will have to use fair and wise 
> criteria on choosing protocols with efficient 
> and right solutions.
> 
> I think that the choice of which other efforts we should 
> use should be at the moment left open!
> 
> Best Regards,
> Georgios
> 
> 
> 
> -----Original Message-----
> From: Jukka MJ Manner [mailto:[email-masked]]
> Sent: dinsdag 3 december 2002 16:34
> To: [email-masked]
> Subject: [NSIS] Re: What is the goal of the analysis draft?
> 
> 
> 
> Hi,
> 
> I strongly believe that looking also at other protocols than RSVP would
> give us more insight into our work, to learn from other efforts, too. We 
> can well find good ideas in other protocols that can help the design of 
> NTLP.
> 
> Jukka
> 
> On Tue, 3 Dec 2002, Georgios Karagiannis (ELN) wrote:
> 
> > Hi
> > 
> > In my opinion, the analysis draft should emphasize
> > the significant positive features but also the main
> > drawbacks of RSVP.
> > 
> > Based on the results of this analysis we could then use 
> > the good things of RSVP and avoid the drawbacks of RSVP
> > during the specification of our "NSIS" transport 
> > protocol (NTLP).
> > 
> > Otherwise, I do not see the reason of spending time
> > on an analysis draft that will not have any value!
> >  
> >  
> > Furthermore, I propose that the analysis draft should 
> > concentrate only on the analysis of the RSVP protocol. I do not 
> > see the point of explaining and analyzing other protocols 
> > than RSVP.
> > We could actually investigate if a simplified version of RSVP could
> > satisfy the requirements of the NTLP.
> > 
> > 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: [email-masked]
Date: Tue, 3 Dec 2002 18:13:36 +0200

Hi All,

The point of looking at other protocols is not to promote other
protocols over RSVP in NSIS, but rather to see what signaling
protocols do well and what they do not do well.  If we can
apply any of the lessons learned to the new work, then we
are ahead of the curve.

John

> From: ext Georgios Karagiannis (ELN)
> [mailto:[email-masked]]
> Sent: 03 December, 2002 17:51
> To: 'Jukka MJ Manner'; [email-masked]'

---

From: [email-masked]
Date: Tue, 3 Dec 2002 18:35:50 +0200

Hi all,

Rather than debating this in some abstract, existential sense,
please comment directly on the draft.  If text is needed,
please suggest.

thanks,
John

> Sent: 03 December, 2002 17:30
> To: Loughney John (NRC/Helsinki); [email-masked]; 
> [email-masked]
> Subject: What is the goal of the analysis draft?
> 
> 
> Hi
>

---

From: [email-masked]
Date: Wed, 4 Dec 2002 06:26:34 +0200

Hi Bob,

> There is far too much micro-engineering is inventing 17 ways to do the
> same thing, and RSVP is not a sufficient framework to bring some order
> to this cahos.  The proper role for the NSIS has taken on the task of
> straightening out this mess.
> 
> My first thought was that writing an analysis draft is a complete waste
> of time.  

The point of doing an analysis was to ensure that what RSVP done
well is captured in the process of doing the NSIS work.  It is a 
non-goal to toss everything learned from RSVP into the trash can
& start over fresh.  I don't envision a massive work effort in
making the analysis, I'd prefer that folks read the current draft,
do a sanity check & see if anything needs to be added.  That being
done, we can move on to bigger and better things.

John

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Wed, 4 Dec 2002 10:11:48 +0100

Hi Bob

>> straightening out this mess.

I agree with you!

>> The original base E2E signaling protocol for QoS with
>> multicasting is a dead issue; nothing is to be gained by writing
>> anything further about it (beyond RFC 2208).  However, describing in
>> some generality the ~10 different signaling protocols currently based
>> on RSVP (or RSVP-TE, etc.) might be useful for helping the NSIS group
>> to understand how to structure the space of ULSPs.  It will require
>> digging into design documents of the ATM Forum, 3GPP, the Optical
>> Interworking Forum, and the ITU, as well as the MPLS WG of the IETF.,
>> where RSVP "extensions" have been defined.

I totally agree!

Best Regards,
Georgios

---

From: [email-masked]
Date: Wed, 4 Dec 2002 18:34:55 +0200

Hi Mike,

>    I guess I disagree. To take a small example, one the
>    problems I found with MIP/RSVP is the route damping
>    problem. That is, an interior node seeing a new PATH
>    for an existing reservation is going to want to back
>    off to dampen flapping. This is great for the normal
>    cause (interfaces bouncing), and lousy for MIP where
>    the topology change is intentional. 
> 
>    Thus, I think it's fairly easy to derive a requirement
>    out of that:
> 
>    o The protocol must allow for explicit and intentional
>      topology changes which are not subject to route
>      flap damping procedures.

I'd suggest that you submit that this as a requirement to
Marcus.

thanks,
John

---

From: [email-masked]
Date: Wed, 4 Dec 2002 19:02:07 +0200

Hi Melinda, Mike & Bob,

> I absolutely agree with this.  I think that right now the
> requirements document suffers a bit from the inclusion of
> things that aren't really requirements (much of the
> scalability section, for example), while it's one function
> of a requirements document to bring out non-obvious
> requirements like this one.  
> 
> Also, while I agree with the need to move as quickly as
> possible, I don't think it's a good idea to try to move
> *more* quickly than it's possible in order to head off
> efforts by other standards bodies.  We need to produce the
> best quality protocol we can within a reasonable time frame,
> and I'd rather see us achieve that by constraining the
> problem than by omitting important pieces of the process.

My current reading of the Requirements doc is that it is 
general requirements document for the problem space.

What you, Mike & Bob seem to be pointing to is much
closer to a sort of input for protocol design.  In
fact, I would like to see a major part of the interim
meeting to be working on such a document.  Mike's document
and Bob's documents have elements which are very close
to what I see as needed.  They are so close, that I have
toyed with the idea of making one of them the starting
point for the work. 

An even better solution would be for you, Bob & Mike
to formulate a document which could be used as input
for the transport protocol.  This need not even be
an Internet draft (though helpful if it was).  Generally,
we need some starting point to start to say what
the transport protocol will & should & should not
do.  I don't think the current requirements document is
really intended to do this.

What do you think about this proposal?

John

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Thu, 5 Dec 2002 10:22:40 +0100

Hi John

I agree with your proposal!

Best regards,
Georgios

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: woensdag 4 december 2002 18:02
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [NSIS] What is the goal of the analysis draft? 

Hi Melinda, Mike & Bob,

John

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Thu, 5 Dec 2002 10:59:15 +0100

Hi Jukka

The requirements document refers to both transport and application layers!

Best regards,
Georgios

-----Original Message-----
From: Jukka MJ Manner [mailto:[email-masked]]
Sent: donderdag 5 december 2002 10:56
To: [email-masked]
Subject: RE: [NSIS] What is the goal of the analysis draft? 

Just a thought: aren't your suggestions related to the "blob" the
protocols is carrying? Thus, the protocol should support upper layer
object agregation (within single messages) and the upper layer objects
should be designed to allow for state aggregation at processing nodes.

Regards,
Jukka

On Thu, 5 Dec 2002, Georgios Karagiannis (ELN) wrote:

> Hi Melinda
> 
> Regarding the scalability term I see your point!
> Maybe we could enlarge the scalability requirements 
> with sentences, such as:
> "when applicable must support state aggregation", 
> "when applicable must support message aggregation", etc.
> 
> Is this acceptable to you?
> 
> Regarding section 5.5.5, I think that it emphasizes 
> the need on achieving high network utilization and therefore,
> it makes sense to have such a requirement.
> 
> Best Regards,
> Georgios
> 
> 
> From: Melinda Shore [mailto:[email-masked]]
> Sent: woensdag 4 december 2002 19:24
> To: Georgios Karagiannis (ELN)
> Cc: [email-masked]
> Subject: Re: [NSIS] What is the goal of the analysis draft? 
> 
> 
> I think that it's pretty clear that "scalability" is not a
> particularly meaningful term when it comes to laying out
> requirements.  I would prefer to see things like "must
> support message aggregation" than "should limit the load on
> devices."   Maybe this needs to be thought of in terms of
> what would happen if it were not included.  Do you think
> that if section 5.5.5 were omitted, people designing a
> protocol would then think "the heck with network
> efficiency?"
> 
> Melinda