Subject: RE: [NSIS] QoS NSLP open issue on error cases with QSPEC stacking

From: [email-masked]
Date: Wed, 25 Feb 2004 09:38:08 +0100

Hi Cheng Hong,

Please see further comments inline.

Best regards,
Sven

"Cheng Hong" <[email-masked]> on 25/02/2004 09:15:30

To:    Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL
cc:    <[email-masked]>, "'McDonald, Andrew'" <[email-masked]>,
       "'Georgios Karagiannis'" <[email-masked]>
Subject:    RE: [NSIS] QoS NSLP open issue on error cases with QSPEC
       stacking

Hi Sven,

Please see a few further comments inline:

> <snip>
> > 1. Should a QNE attempt to recover from an unrecognised QSPEC stack
> > ...
> >       a. ... in addition to sending an error message upstream?
> >       b. ... instead of sending an error message upstream?
> > Suggestion: yes, in addition to sending an error
>
> Does this also depend on what the error message contains and
> how the QNE peer responds to the error message? If the error
> message would simply cause the peer QNE to resend the entire
> QSPEC stack, would the recover still be necessary?
>
> Sven>> The idea underlying the suggestion is to limit the signalling
> Sven>> delay
> while still notifying upstream peers of a potential problem.
> It is therefore intended for the period before (any of) the
> upstream QNEs react to the notification by e.g. resending the
> stack. If the recovery turns out to be wrong, resending the
> stack will solve it the next time around. If it was correct,
> the signalling delay is minimised.

So in this case, the QNE must be able to reconginize the certain QSPEC has
already been processed upon receiving the retransmitted QSPEC stack. The
RSN
could be used, but it means different QoS Model would have to maintain its
own record of the current sequence number.

Sven>> The RSN is used for this (QNE keeps track of his own current
sequence number and QoS model ID, see state table). If RSN or QoS model ID
changes then the update is regarded as a new reservation.

> > 2. How far can a QNE inspect the QSPEC stack?
> >       a. only the next QSPEC
> >       b. the entire stack
> > This is essentially a trade-off between the amount and type
> of errors
> > that you want to recover from and the complexity. Suggestion is to
> > allow inspection of the entire stack in case the edge QNE
> is the same
> > for several layers.
>
> Maybe this also depends on whether the recover is possible
> based on the next QSPEC. If the recover isn't possible, i.e.
> whole stack of QSPEC needs to be resent, there is no need to
> go any furhter.
>
> Sven>> I'll try to give an example:
>
> +-----+        QSpecC            +-----+      +-----+
> | QNE1|------------------------->|     |      |     |
> +-----+                          |     |      |     |
>                                  |     |      |     |
>           +-----+    QSpecB      |     |      |     |
>           | QNE2|--------------->| QNE4|----->| QNE5|
>           +-----+                |     |      |     |
>                                  |     |      |     |
>                     +-----+QSpecA|     |      |     |
>                     | QNE3|----->|     |      |     |
>                     +-----+      |     |      |     |
>                                  +-----+      +-----+
>
> Suppose QNE4 is the edge of the domains in which QSpecs A, B
> and C are valid. The stack looks like QSpecA
> (top)-QSpecB-QSpecC. QNE5 only knows QSpecC. Suppose for some
> reason QNE4 does not terminate domains A and B, then QNE5 can
> recover from the error by inspecting the stack 2 deep (until
> it finds QSpecC). The correct behaviour is then to discard
> everything above. This means that it might be useful to go
> deeper into the stack.

Yes. I agree that in this case, the QNE should inspect the whole stack
until
it found one recognized Qspec.

> > 3. What should be done with the stack when a deeper QSPEC is
> > recognised
> >       a. leave intact
> >       b. discard all QSPECs above the recognised QSPEC
> > Suggestion: discard everything above. This avoids that all
> subsequent
> > QNEs need to do the same inspection.
>
> This is closely related to the point 2. Does this assume that
> there is no more unrecognized QSPEC between the "deeper
> QSPEC" and the end of the stack?
>
> Sven>> No, in the example above QSpecB (unrecognised) is
> between QSpecA
> (unrecognised) and QSPecC (recognised).
>
>

My question is if there is any possibility that an Qspec D (unrecognized)
could be appear after QSpecC (recongnized)? E.g. QSpecA
(unrecognized)-QspecB (unrecognized)-QspecC (recognized)-QspecD
(unrecognized)

Sven>> Yes, that would be possible if a domain with a wider scope than
QSpecC exists (e.g. end-to-end)

Cheers

Cheng Hong

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Kappler Cornelia <[email-masked]>
Date: Wed, 25 Feb 2004 11:49:23 +0100

Hi Sven,

regarding 

"3. What should be done with the stack when a deeper QSPEC is recognised
       a. leave intact
       b. discard all QSPECs above the recognised QSPEC
Suggestion: discard everything above. This avoids that all subsequent QNEs need to do the same inspection."

I think we need to find out whether there are cases where discarding all QSpecs above may not work, i.e. where the nesting of QoS model domains is somehow broken (by malfunctioning or malconfigured nodes), such that too much of the stack is thrown away. E.g. The stack has QSpecs A-B-C, and QSpec A is not removed at the border of domain A by QNE a2. The next QNE x doesnt recognize A, nor B, so it removes the two and works on C. However somehow the QNE b1 after QNE x is still in domain B and would need QSpec B. Can we come up with such a scenario? And if we do, would this involve so many problematic QNEs that there is no way to recover from the problem without delay and more messages anyways (so option (b) is fine anyways)?

The following picture illustrates what I am trying to say:

normal operation. Probably QNE x would not be on the path, or at least would not need to interprete QSpec B:

ABC    -->   BC   -->     BC
QNE a1      QNE a2       QNE b1

faulty operation: Because of QNE a2 malfunctioning, may be it is broken down, the message gets routed via QNE x, which is outside domain B, or at least not configured to handle QSpec B, but then reenters the proper path via domain B:

ABC    -->  ABC   -->  C   -->   ?
QNE a1     QNE a2     QNE x    QNE b1

Is such a scenario at all possible?

Cornelia
   
> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] Im 
> Auftrag von [email-masked]
> Gesendet: Mittwoch, 25. Februar 2004 09:38
> An: Cheng Hong
> Cc: [email-masked]; 'McDonald, Andrew'; 'Georgios Karagiannis'
> Betreff: RE: [NSIS] QoS NSLP open issue on error cases with 
> QSPEC stacking
> 
> 
> Hi Cheng Hong,
>

---

From: "McDonald, Andrew" <[email-masked]>
Date: Wed, 25 Feb 2004 11:08:31 -0000

Hi Cornelia,

Kappler Cornelia wrote:
> regarding
> 
> "3. What should be done with the stack when a deeper QSPEC is
>        recognised a. leave intact
> I think we need to find out whether there are cases where discarding
> all QSpecs above may not work, i.e. where the nesting of QoS model
> domains is somehow broken (by malfunctioning or malconfigured nodes),
> such that too much of the stack is thrown away. E.g. The stack has
> QSpecs A-B-C, and QSpec A is not removed at the border of domain A by
> QNE a2. The next QNE x doesnt recognize A, nor B, so it removes the
> two and works on C. However somehow the QNE b1 after QNE x is still
> in domain B and would need QSpec B. Can we come up with such a
> scenario? And if we do, would this involve so many problematic QNEs
> that there is no way to recover from the problem without delay and
> more messages anyways (so option (b) is fine anyways)? 

Yes. I agree.

Essentially the whole problem is one of trying to recover in the face of misconfiguration anyway. If one thing is broken, how correct should we assume later elements to be.

Point 3 can be thought of as 'the edge was missing, so should this node make itself the new edge?'. If it is a node in the middle of the B domain that is 'wrong' then becoming a new edge could break things even more.

> normal operation. Probably QNE x would not be on the path, or at
> least would not need to interprete QSpec B:
> 
> ABC    -->   BC   -->     BC
> QNE a1      QNE a2       QNE b1
> 
> faulty operation: Because of QNE a2 malfunctioning, may be it is
> broken down, the message gets routed via QNE x, which is outside
> domain B, or at least not configured to handle QSpec B, but then
> reenters the proper path via domain B:
> 
> ABC    -->  ABC   -->  C   -->   ?

I think that is a key question. It is not obvious how to prevent it.

I suppose, in a way we are asking: 'how are people going to get their network configuration wrong?', which is rather a difficult one to answer.

If the problem is that 'edge' nodes don't undo QSpec stacking, then you might want the node receiving the unknown QSpec to become the edge (look deeper, and strip). You probably also want to send back error messages, asking the previous node to become the edge (don't send me a QSpec for that qos model again).

If problem is 'non-edge' nodes that don't understand QoS models they should, then you want things to carry on as if that node wasn't there (possibly look deeper, but don't strip). In this case, sending errors back might also be the wrong answer (if it tells previous nodes not to send something they should be sending).

regards,
Andrew

---

From: Kappler Cornelia <[email-masked]>
Date: Thu, 26 Feb 2004 10:37:19 +0100

Hi Andrew, 

I also agree putting too much "intelligence" into QNEs (i.e. assumptions on what went wrong and hence how it is to be fixed) may result in hard-to-understand system behaviour and backfire (i.e. not speed up processing). 

On the other hand, imagine a QNI trying to set up a reservation with an unknown QNR many domains away (e.g. reserving IP telephony resources between Europe and the Solomon Islands). Of course the QNI doesnt know what QoS model the QNR understands. So it will pick a "well known" QoS model for the first QSpec, and then may be stack a local QoS model on top. At the border of QNIs domain, the local QSpec will be popped, and possibly, depending on SLAs between domains, the bottom QSpec will be rewritten (is this allowed by qos-nslp?). So the RESERVE proceeds through a multitude of domains. Now one domain somewhere does not recognize the QoS model in the bottom QSpec. Do we really want to stop the RESERVE until this domain and the originating domain came up with a solution? May be a "graceful fallback" would be to send an error message, and continue to forward the RESERVE and put up with one domain on the path not reserving resources. This is similar to how RSVP works I believe.

This raises the question of whether we should have a "default QoS model" that must be understood by everybody (a can of worms, I know, so probably not)? 

How would the "graceful fallback" be realized? Popping a QSpec when there is no other left is no good (another reason why the original idea needs amendment). So may be the QNE who does not understand the topmost QSpec tags it. The next QNE would again try and interpret the topmost object. If it succeeds, apparently (assumption!) the QNE before was _within_ the QoS model domain but malconfigured. The RESERVE proceeds with the tag which tells the QNE popping the topmost QSpec one (or at least one - depending on how many bits we spend on this) QNE was unable to reserve resources. May be because we already sent the error message, the tag is redundant and not necessary. Of course this procedure doesnt help in the case of a QNE not popping a QSpec it was supposed to pop. In this case we produce processing overhead because all QNEs up to the QNR try to interpret a QSpec they are unable to interprete, and the reservation fails anyways.

Thinking aloud (and hoping such issues have not yet been discussed at length on this list...), Cornelia

> Von: McDonald, Andrew [mailto:[email-masked]] 
> Gesendet: Mittwoch, 25. Februar 2004 18:15
> An: 'Kappler Cornelia'; [email-masked]'; Cheng Hong
> Cc: [email-masked]; 'Georgios Karagiannis'
> Hi all,
> Some further ruminations.
> 
> Looking at this in a different way, and going back to the 
> fundamentals: is what is being sent a "stack of QSpecs", or a 
> "choice of QSpecs"?
> 
> I think we're talking about a "stack":
> The source QNE is requesting the resources in the top object. 
> So, actually processing a different object is wrong (we would 
> be reserving something different to what we were asked for). 
> Then, since it is the source QNE who asked for that QSpec 
> (and sent it with the expectation of it being honoured), the 
> responsiblity for fixing the problem should be pushed back to it.
> 
> It is an error case anyway, so correctness should be the 
> goal, rather than making it fast/seamless. It is desirable to 
> limit the error propagation - if you know you have got bad 
> data (a QSpec for an unsupported qos model), you should limit 
> how far this gets propagated. Either 'fixing' the set of 
> QSpecs at the receiving QNE, or forwarding them unchanged 
> would result in the error affecting the resources requested 
> at subsequent nodes.
> 
> If you were to go with the "choice" view, then the source QNE 
> would be asking for any one of the QSpecs in the set to be 
> processed. However, you still need to handle the case where 
> none of the QSpecs can be understood. Allowing the receiving 
> QNE to choose also means that the RESERVE does not have a 
> deterministic result from the sending QNEs point of view - it 
> doesn't know which QSpec will be used.
> 
> My conclusion would be that the receiving node should not 
> attempt any recovery (looking deeper into the set of QSpecs 
> and maybe subsequently stripping off QSpecs). Instead it 
> should just send an error back and leave the responsibility 
> for recovering to the sending QNE.
> 
> How does that argument sound?
> 
> 
> Andrew
> 
> McDonald, Andrew wrote:
> > I suppose, in a way we are asking: 'how are people going to 
> get their
> > network configuration wrong?', which is rather a difficult one to
> > answer.  
> > 
> > If the problem is that 'edge' nodes don't undo QSpec stacking, then
> > you might want the node receiving the unknown QSpec to become the
> > edge (look deeper, and strip). You probably also want to send back
> > error messages, asking the previous node to become the edge (don't
> > send me a QSpec for that qos model again).    
> > 
> > If problem is 'non-edge' nodes that don't understand QoS models they
> > should, then you want things to carry on as if that node 
> wasn't there
> > (possibly look deeper, but don't strip). In this case, 
> sending errors
> > back might also be the wrong answer (if it tells previous nodes not
> > to send something they should be sending).    
> 
> 
> -- 
> Registered Office: Roke Manor Research Ltd, Siemens House, 
> Oldbury, Bracknell,
> Berkshire. RG12 8FZ
> 
> The information contained in this e-mail and any attachments 
> is confidential to
> Roke Manor Research Ltd and must not be passed to any third 
> party without
> permission. This communication is for information only and 
> shall not create or
> change any contractual relationship.
>

---

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 26 Feb 2004 09:56:25 -0000

cornelia,

my mental model of operation is to consider that 
- nodes where reservations are installed understand the
  QoS models that they accept reservations for (this is
  obvious)
- nodes which request reservations of other nodes must
  be able to request it in language that those 'other'
  (neighbour) nodes understand (not quite so obvious
  but reasonable IMHO)

in that case, the bit in your scenario where it goes

> So the RESERVE proceeds through a multitude of 
> domains. Now one domain somewhere does not recognize the QoS 
> model in the bottom QSpec.

is a should-not-happen error condition (i.e. I think this
is an assumption we should make): 
- the previous domain understood and installed the 
  reservation in its own nodes
- it knows it is connected to a neighbour domain
- it knows (or should find out as a matter of urgency) if
  that neighbour doesn't support a QoS-model that it itself
  does (whether that is the only model on the stack or just
  the topmost one doesn't really matter)
- in that case, it should be able to translate its own 
  understanding of the requested QoS (it must have an 
  understanding, since it installed the reservation...)
  into language that the neighbour does understand.

some details: i assumed that re-writing was allowed only
in so far as the qos model specified it (qos models might
allow re-writing of some fields but not others, for example).
I assumed that arbitrary re-writing is not possible (unless 
you terminate the signalling session at a node and start
a new one) - that is what the stacking is for, to make
such things unnecessary.

on the gracefull fallback case: this is worth thinking about.
conceptually it is not much different from passing through
an NSIS-unaware node (and we certainly have to be capable of
that!)

cheers,

robert h.

> -----Original Message-----
> From: Kappler Cornelia [mailto:[email-masked]]
> Sent: Thursday, February 26, 2004 09:37
> To: McDonald, Andrew; Kappler Cornelia; 
> [email-masked]';
> Cheng Hong
> Subject: AW: [NSIS] QoS NSLP open issue on error cases with QSPEC
> stacking
> 
> 
> Hi Andrew, 
> 
> I also agree putting too much "intelligence" into QNEs (i.e. 
> assumptions on what went wrong and hence how it is to be 
> fixed) may result in hard-to-understand system behaviour and 
> backfire (i.e. not speed up processing). 
> 
> On the other hand, imagine a QNI trying to set up a 
> reservation with an unknown QNR many domains away (e.g. 
> reserving IP telephony resources between Europe and the 
> Solomon Islands). Of course the QNI doesnt know what QoS 
> model the QNR understands. So it will pick a "well known" QoS 
> model for the first QSpec, and then may be stack a local QoS 
> model on top. At the border of QNIs domain, the local QSpec 
> will be popped, and possibly, depending on SLAs between 
> domains, the bottom QSpec will be rewritten (is this allowed 
> by qos-nslp?). So the RESERVE proceeds through a multitude of 
> domains. Now one domain somewhere does not recognize the QoS 
> model in the bottom QSpec. Do we really want to stop the 
> RESERVE until this domain and the originating domain came up 
> with a solution? May be a "graceful fallback" would be to 
> send an error message, and continue to forward the RESERVE 
> and put up with one domain on the path not reserving 
> resources. This is similar to how RSVP works I believe.
> 
> This raises the question of whether we should have a "default 
> QoS model" that must be understood by everybody (a can of 
> worms, I know, so probably not)? 
> 
> How would the "graceful fallback" be realized? Popping a 
> QSpec when there is no other left is no good (another reason 
> why the original idea needs amendment). So may be the QNE who 
> does not understand the topmost QSpec tags it. The next QNE 
> would again try and interpret the topmost object. If it 
> succeeds, apparently (assumption!) the QNE before was 
> _within_ the QoS model domain but malconfigured. The RESERVE 
> proceeds with the tag which tells the QNE popping the topmost 
> QSpec one (or at least one - depending on how many bits we 
> spend on this) QNE was unable to reserve resources. May be 
> because we already sent the error message, the tag is 
> redundant and not necessary. Of course this procedure doesnt 
> help in the case of a QNE not popping a QSpec it was supposed 
> to pop. In this case we produce processing overhead because 
> all QNEs up to the QNR try to interpret a QSpec they are 
> unable to interprete, and the reservation fails anyways.
> 
> Thinking aloud (and hoping such issues have not yet been 
> discussed at length on this list...), Cornelia
> 
>

---

From: "McDonald, Andrew" <[email-masked]>
Date: Thu, 26 Feb 2004 14:32:02 -0000

Hi all,

From an NSLP perspective, I think that the important thing here is not whether the NTLP is using datagram or connection mode, but rather whether reverse routing state exists or not.

If you haven't got reverse routing state then you can drop the message or forward it (as if you weren't an NSIS node at all). There is also enough information at the GIMPS level (from the IP header of the datagram mode message) to get something back one GIMPS hop.

Andrew

Georgios Karagiannis wrote:
> Hi Sven, Andrew, Robert
> 
> I also agree with the conclusion derived by Andrew.  The sending node
> has to be
> informed about the error. Since the sending node has the required
> information
> on making such a decission, and other nodes may not, let the
> responsibility for recovering to the sending node.
> 
> Note, however that there are different ways on how the sending node
> can be informed
> about this error. These ways could depend on the used NTLP mode.
> 
> Best Regards,
> Georgios
> 
> ----- Original Message -----
> From: <[email-masked]>
> To: "Hancock, Robert" <[email-masked]>
> Cc: "'Kappler Cornelia'" <[email-masked]>; "McDonald,
> Andrew" <[email-masked]>; "Cheng Hong"
> <[email-masked]>; <[email-masked]>; "'Georgios Karagiannis'"
> <[email-masked]> 
> Sent: Thursday, February 26, 2004 2:09 PM
>> Hi Robert, Andrew, all,
>> I am starting to feel a lot for Andrew's proposed solution. However,
>> I am wondering if the correct answer might depend on the mode used
>> by GIMPS, i.e. 
>> - connection mode: reasonable to assume you know which models are
>> supported by your peer 
>> - datagram: not so reasonable to make this assumption
>> 
>> I would say that in connection mode, you just send an error message
>> back and let the sender solve the problem (i.e. become the edge of
>> the domain if necessary). The solution seems to be either resend in
>> datagram mode (hence tunneling through the offending (Q)NE) or to
>> terminate and look deeper. 
>> 
>> In datagram mode, maybe you should just pass on the message as is
>> and behave like an NE? 
>> 
>> Sven
>> 
>> 
>> 
>> 
>> 
>> 
>> "Hancock, Robert" <[email-masked]> on 26/02/2004 10:56:25
>> 
>> To:    "'Kappler Cornelia'" <[email-masked]>,
>>        "McDonald, Andrew" <[email-masked]>, Sven VAN DEN
>>        BOSCH/BE/ALCATEL@ALCATEL, Cheng Hong <[email-masked]>
>> cc:    [email-masked], "'Georgios Karagiannis'"
>> <[email-masked]> Subject:    RE: [NSIS] QoS NSLP open issue
>> on error cases with QSPEC        stacking 
>> 
>> 
>> cornelia,
>> 
>>   QoS models that they accept reservations for (this is   obvious)
>>   (neighbour) nodes understand (not quite so obvious   but
>> reasonable IMHO) 
>> 
>>>>> I suppose, in a way we are asking: 'how are people going to get
>>>>> their network configuration wrong?', which is rather a difficult
>>>>> one to answer. 
>>>>> 
>>>>> If the problem is that 'edge' nodes don't undo QSpec stacking,
>>>>> then you might want the node receiving the unknown QSpec to
>>>>> become the edge (look deeper, and strip). You probably also want
>>>>> to send back error messages, asking the previous node to become
>>>>> the edge (don't send me a QSpec for that qos model again).
>>>>> 
>>>>> If problem is 'non-edge' nodes that don't understand QoS models
>>>>> they should, then you want things to carry on as if that node
>>>>> wasn't there (possibly look deeper, but don't strip). In this
>>>>> case, sending errors back might also be the wrong answer (if it
>>>>> tells previous nodes not to send something they should be
>>>>> sending). 
>>>> 
>>>> 
>>>> --
>>>> Oldbury, Bracknell, Berkshire. RG12 8FZ
>>>> 
>> Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury,
>> Bracknell, Berkshire. RG12 8FZ
>> 
>> The information contained in this e-mail and any attachments is
>> confidential to Roke Manor Research Ltd and must not be passed to
>> any third party without permission. This communication is for
>> information only and shall not create or change any contractual
>> relationship. 

-- 
Andrew McDonald, Senior Engineer
Roke Manor Research Ltd, Romsey, Hants  SO51 0ZN
Phone +44 1794 833833   Fax +44 1794 833434

---

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 26 Feb 2004 14:43:29 -0000

hi,

> From an NSLP perspective, I think that the important thing 
> here is not whether the NTLP is using datagram or connection 
> mode, but rather whether reverse routing state exists or not.

precisely. indeed, a future NTLP spec might not have a connection
mode at all, or it might divide datagram and connection mode
differently, or it might call them something else. (in fact,
the NSLP drafts should not refer to datagram/connection mode
distinctions since this is a GIMPS design feature which is 
explicitly intended not to be visible externally except in terms
of the performance attributes of the message transfer.)

whether to store reverse routing state is one of those 
attributes, and ...

> 
> If you haven't got reverse routing state then you can drop 
> the message or forward it (as if you weren't an NSIS node at 
> all). There is also enough information at the GIMPS level 
> (from the IP header of the datagram mode message) to get 
> something back one GIMPS hop.

[just to reassure you: if a message arrived in C-mode you 
can always send back a message along the same association;
D-mode messages always include the Node-Addressing of the 
peer that sent it, so you can respond direct to that.]

This is incidentally another reason for responding with an
error as soon as possible, rather than trying to propagate
the message any further. If you have a region of stateless
nodes but only decide the error is fatal at the egress edge,
you have (maybe) no way to get back to the ingress edge.
If you decide it is fatal as soon as possible, there is a
stronger likelihood of getting back to a node which knows
enough about what is going on to be able to fix it. (If you
have a region of stateless nodes where they don't all understand
the same QoS model, you are in real desparate trouble, but
it's probably the sort of trouble which has to be handled via
network management anyway.)

r.

---

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 1 Mar 2004 01:51:47 -0000

hi xiaoming,

> Hancock, Robert wrote:
> Just from a programmer's view:
> 
> In TCP, connections are duplex but conceptually "uni-directional" 
> between a server and a client: once a connection is set up, 
> data can be 
> sent by the server back toward the client, but the control is in the 
> client side (i.e., these data are sent when the server passively 
> acquires a request from the client). Of course with some tricks in 
> programming, a true uni-directionality can be made possible, 
> but at cost 
> of possibly more complex socket operation. As a tradeoff, another 
> connection - we just need one connection in maximum per direction 
> between a GIMPS-peer pair - in the reverse direction could be 
> an viable 
> option.

GIMPS messaging associations are assumed to be full duplex (i.e.
once it has been set up, it can be used identically by either end).
TCP can be used in this way. i'm not sure why having a pair of
conceptually uni-directional associations would make life easier.
(i'm open to suggestions.)

> If the data does not concern with any other nodes in between 
> these two 
> D-mode peers (e.g., just to acknowledge the previous D- sender), this 
> can work. However, if in the reverse way changing something in the 
> middle is desired, we have to rely on PHOP info as in RSVP.

The Node-Addressing object in GIMPS is the precise analogue
the RSVP PHOP object. So, I think we are actually saying the
same thing here.

cheers,

r.

> Cheers,
> Xiaoming