Subject: RE: NO messages

From: "Martin Stecher" <[email-masked]>
Date: Thu, 3 Jul 2003 18:01:16 +0200

Great. We have it, I guess.

Summary:

- NO and NR have optional named parameter SG, which has an uni value sg-id

- sg-id was previously created by SGC

- If NR is sent in response to NO with SG parameter, NR also needs the same SG parameter

- TS has mandantory sg-id anonymous parameter; the optional "service" parameter will go away

Regards
Martin

> -----Original Message-----
> From: Alex Rousskov [mailto:[email-masked]]
> Sent: Thursday, July 03, 2003 5:13 PM
> To: OPES WG
> Subject: RE: NO messages
> 
> 
> 
> On Thu, 3 Jul 2003, Martin Stecher wrote:
> 
> > Looks good. It is either it now or it is very close. Let's check for
> > finetuning:
> >
> > 1. The sequence
> >      P:NO (profile1, profile2, profile3)
> >        Service-Group: sg-id;
> >      S:NR profile2;
> >    negotiates that profile2 will be used in transactions for sg-id.
> >    There is no direct switch to profile2 on the connection.
> 
> Correct.
> 
> >      P:NO (profile1, profile2, profile3)
> >      S:NR profile2;
> >
> >    negotiates profile2 on a connection level independend of any
> >    service or tranaction. Switch to profile2 is implied with the
> >    response.
> 
> Correct.
> 
> >    We may want to make this more obvious by adding a parameter also
> >    to the NR message that acknolowledgs that there is no direct
> >    profile switch.
> 
> I thought about doing that as well. Let's make Service-Group mandatory
> in the response. Semantically, it would mean that the responder
> understands that we are negotiating service group settings (other than
> that, there is no information in that parameter in NR).
> 
> Let's also call the parameter SG since it is going to be used a lot.
> 
> > 2. More NO-NR dialogs are introduced with this approach. If one
> > agent wants to check for several service group profile after each
> > other, it always needs to wait for a NR message before sending the
> > next NO message.
> 
> In some cases, it is possible to do optimistic negotiation (sending
> offers without waiting for responses). We will need to document that
> somehow (provide an example?) but the current spec wording should
> allow for that.
> 
> For example (each line represents a moment in time):
> 
> 	Processor                   Server
> 	send NO#1
> 	send NO#2
> 	send NO#3                   recv NO#1
> 	send NO#4                   send NR to NO#1
>         recv NR to NO#1             recv NO#2
> 	send NO#5                   send NR to NO#2
> 	recv NR to NO#2
> 	TS 1 sg-id from NO#5        recv NO#3
> 	...                         ...
> 
> As you can see, there is ordering/matching of NO and NR messages, but
> there is no synchronization at all.
> 
> Note that the first TS is also optimistic. It may be rejected by the
> server if NR to NO#5 is negative. If processor wants to play it safe,
> it can wait for the corresponding NR before starting a transaction
> using its sg-id.
> 
> >    The rid parameter had been removed from NO/NR before. Do we need
> >    to add it again?
> 
> It will not help because there can be only one negotiation taking
> place at any given time. This may seem like a contradiction to the
> optimistic negotiation statement above, but it is not.
> 
> > Eventually we can combine 1 and 2 by making sg-id an anonymous
> > parameter and let it play the role of rid. But is it good to have
> > that functionality through a second and optional parameter of NO/NR?
> > Not sure.
> 
> We should try to avoid semantic overloading in protocols.  Moreover, I
> do not think rid helps here (see above). Does the availability of
> optimistic negotiation address your concerns?
> 
> Alex.
> 
> ------------------------------------------------------------
> This mail has been scanned by debian3-smtp
> (WebWasher 4.4 fcs Build 556)
> ------------------------------------------------------------
>

---

From: jfcm <[email-masked]>
Date: Wed, 09 Jul 2003 16:46:06 +0200

I apologize for not having participated lately to the work of the WG, being 
taken by others important (to my familly) tasks. I am trying to bring me up 
to speed now the fight seems over :-).

An important point came accross recently at TFIPv6 and through some words 
of Tom Leighton (Akamai).  It could be summarized this way "are routing and 
addressing" to be related? Today the routing is fixed tables dependant and 
addresses are ISP dependant. There are aound 140.000 routes in these 
tables. Rumors (? may be someone knows better) have that over 200.000 
routes there might be instability.

I observe that many problems currently discussed over IPv6 would disapear 
would the SLA (Second Level Address) be totally independant from the TLA 
(Top Level Adress). This would mean that the begining of the IPv6 address 
would be used identify the physical network (as the TLD indentifies the 
virtual network). And the SLA would identify the physical System (as does a 
telephone number which uniquely identify a mobile whatever the local 
network used to call it - for example abroad).

This would for example permit to support Catenet (the archtecture of Louis 
Pouzin they considered for a while where the inputs of all the links are 
concatenated on a per port basis, so you may receive data through a non 
DoSed ISP). This would simplify the knowledge and the organization of 
dynamic tables for routing.

To test the concept an archtecture is necessary without redesigning 
routers. Could the architecture be a network or OPES servers used to route 
datagrams over OCP.

1. let suppose that I use 60 or 100 OPES servers.
2. Each of them has physical links to Hosts and to other OPES.
3. each time a datagram is sent a dispatcher looks at the destination IP 
address and if it is among the connected Hosts it builds an OCP path to 
reach that host as a list of {OPES server:port nr}.

a) I understand that OCP could support it
b) I understand that OCP could support many additional services such as 
killing a blocked connexion?
c) this is software, but I would be interested in comments about the 
probable speed?
d) how OCP could support an exploration of the OPES servers network at 
start (or on demand) to kown the most simply the topology of the network 
and of the Hosts ports (this can be a simple application, but would you see 
some OCP features that would help verification, speed, etc.?)
e) obviously this could be partly hard coded and gain speed and stability. 
CommentsN

One of the interesting feature I suppose OCP would support easily would be 
a fast and no loop routing in having the current machine removed from the 
list of the {OPES:Ports] when the datagram is sent. This simple service by 
the current OPES server would create a true pipe, OCP being able to report 
the end success and the on-path failures and request alternate routing. The 
OPES servers could bufferise the data until they are told the next node 
forwarded them (or the first server until data reached the end). If the 
next node failedn an alternative path could be requested and no datagram 
could be lost. If I am right OCP would also make sure there is no intruding 
datagrams?

jfc