Subject: Re: [Anima-signaling] Two definite proposals for GRASP protocol change

From: Carsten Bormann <[email-masked]>
Date: Sun, 10 Jan 2016 14:38:04 +0100

Hi Brian,

looking over the CDDL again, I'm stumbling over the presence and absence
of an initiator in the messages.

First of all, the overall pattern

     message /= [MESSAGE_TYPE, session-id, ?initiator, *option]

(3.7.1) is ambiguous in that an initiator looks just like an option, so
you cannot write a general parser that understands this pattern.
(This is OK since the specific messages define whether an initiator is
present or not, but it still feels a bit odd.)

More odd to me is that the session-id only makes sense in conjunction
with the initiator, but the latter is not always given.  I can't quite
make rhyme and reason out of when it's there and when not.  Maybe that
should be explained in the text (beyond what's in 3.6), including how
the initiator is implied when not present in the message (source IP
address of UDP packet?).  Maybe I'm just confused that discovery pairs
with response, and not request.  Oh, and there is a certain danger that
implementation errors in this space are not caught until two initiators
happen to use the same session-id.  (Protocols with infrequent cases
where certain protocol behavior becomes important for correctness are
harder to test.)

(I also have a suspicion that the protocol might not react well when
responses are sent from IP addresses different than to which the request
was sent.  It is harder to get this right with UDP than it should be.)

Editorially, I'm not sure I have said that, but I'm not a big fan of the
non-parsable ("fragmentary") pieces of CDDL in the CDDL fragments.
They make it a bit harder to extract all the fragments and check
automatically whether they are consistent with the overall structure in
section 6.  (They also make we want to quibble over the exact
fragmentary syntax to be used.)  Instead of

     initiator /=   ; defined below
     objective /=   ; defined below

how about:
     ; initiator and objective are defined below

(But then, saying four times that initiator and six times that objective
is defined below doesn't make a lot of sense either.)

All this is more in the sense of food for thought than in the sense of
"Houston, we have a problem".

Grüße, Carsten

Brian E Carpenter wrote:
> On 11/12/2015 03:50, Carsten Bormann wrote:
>> ... and looking at the CDDL after extracting it manually:
>>
>> MESSAGE_TYPE is what kind of thing?
>>
>> Assuming this might need to extensible, I think specifying something like
>>
>> MESSAGE_TYPE = 0..255 ; a constant defined below
>>
>> might help (alternatively: 0..99, if you want to keep them separate from
>> option numbers).
> 
> Yes, thanks.
> 
>> MESSAGE_TYPE = M_DISCOVERY / M_RESPONSE / M_REQUEST / M_NEGOTIATE /
>> M_END / M_WAIT
>>
>> (We might also define `option` and `OPTION_TYPE`, where the former
>> includes the ip locator options as well as the options built from type
>> numbers.)
> 
> Might be cleaner.
> 
>> s/tstr/text/g, I'd say.
> 
> Yes
> 
>> What does it mean to use the same objective-name with different
>> objective-flags?
> 
> You use D when only conducting discovery, and N or S when also
> conducting negotiation or synchronization respectively. It's possible
> these flags are not really needed - to be frank I will know that when
> I have completed coding my prototype. If I never need to test the flags
> they can be removed.
> 
> Regards
>    Brian
> 
>> Grüße, Carsten
>>
>>
>> Carsten Bormann wrote:
>>> Brian E Carpenter wrote:
>>>> 1)
>>>>
>>>> I invented the PEN field so I think I can also kill it. My proposal is that we take
>>>> this out of the protocol itself. We state that an objective's name is ":whatever" if
>>>> it's generic and "vendorString:whatever" if it's vendor specific. The formal
>>>> definition of vendorString is that it's a unique UTF-8 string not including ":".
>>>> The format MAY be an FQDN, an email address, or a PEN (represented as a decimal
>>>> number).
>>> With the last sentence, there is some hope of uniqueness.
>>>
>>> (Of course, we have about a million ways of doing this already in the
>>> IETF; URNs etc., but the above selection sounds good.)
>>>
>>> There is no need for the initial : if you stipulate that generic
>>> (registered) objectives cannot contain a :.
>>>
>>>> As far as GRASP is concerned, an objective name is now simply a string.
>>>> Simpler protocol, simpler code.
>>> Sounds good.
>>>
>>>
>>>> 2)
>>>>
>>>> Add a global IP address in all Discovery and Response messages, which is
>>>> a valid address for the initiator, to avoid the remote chance of clashing
>>>> session IDs. 
>>> 1) I may not have a global address yet at the time I build such a
>>> message, right?
>>>
>>> 2) Because people will start using these fields for all kinds of things
>>> (starting side conversations etc.), I'd rather be careful about adding
>>> mechanism that implies some semantics (here: that of an IP address).
>>>
>>> Better to mix in more of this information into a session ID (which needs
>>> to be long enough to make clashes after a reboot unlikely).
>>>
>>>
>>>> I'm happy. My Python code for GRASP discovery is beginning to work.
>>>> This doesn't look much, but it's telling me there is something in the
>>>> discovery cache:
>>>>
>>>>>>> discovery_cache[0].asa_locators[0].locator
>>>>     IPv6Address('2406:e007:6917:1:28cc:dc4c:9703:6781')
>>>>>>> discovery_cache[0].objective.name
>>>>     ':Boot'
>>>>>>> discovery_cache[0].objective.disc
>>>>     True
>>>
>>> Nice!
>>>
>>> One thing I'd like to see is extractable CDDL.
>>>
>>> 1) Right now, I can't use the usual XPath expression
>>>
>>>    //artwork[@type='CDDL']/text()
>>>
>>> because the artwork elements don't have type attributes.
>>>
>>> 2) The "fragmentary CDDL" concept does not work if the extracted CDDL is
>>> to be useful to run checks over it etc.  So, I'd change constructs of
>>> the form
>>>
>>>      option /=      ; one of the options defined below
>>>
>>> into
>>>
>>>      ; use
>>>      ;    option /= ...
>>>      ; to define choices for the options.
>>>
>>> (BTW, please have a look at
>>>
>>> https://tools.ietf.org/html/draft-greevenbosch-appsawg-cbor-cddl-07#appendix-B.1.5
>>>
>>> for a way to combine a general format with specific choices.)
>>>
>>> Grüße, Carsten
>>>
>>> _______________________________________________
>>> Anima-signaling mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/anima-signaling
>>>
>>>
> 
> _______________________________________________
> Anima-signaling mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima-signaling
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 11 Jan 2016 07:52:37 +1300

Hi Carsten,
> present or not, but it still feels a bit odd.)

You are correct. That general pattern is not in the definitive CDDL
in Section 6 "CDDL Specification of GRASP". I was just looking for a
way to express the general form of the messages. Would it be better to
just say it in words at this point, without using pseudo-CDDL?

> address of UDP packet?).

The issue only arises at all because of the need to relay discovery
and flood packets from one interface to another. In all other cases
the source address of the packet is fine for disambiguating sessions.
And in my implementation, the issue doesn't even arise for relayed
discovery messages, because it proved easier to launch a new discovery
session than to propagate the old one.

You know, I'm going to look at my code again. If I can do the same trick
for flood messages when they are relayed, we just wouldn't need the
stupid initiator field at all.

> Maybe I'm just confused that discovery pairs

True, but during testing I had the opposite problem: responses being
delivered to the wrong thread, which was detected because the session-ids
did not match. That pointed to a quite serious implementation blunder.
> was sent.  It is harder to get this right with UDP than it should be.)

Yes. That's one reason my implementation is lazy and only supports
TCP for unicast sessions.

> "Houston, we have a problem".

I certainly don't have a closed mind on that. However, it would be a bit
annoying for the reader to be told many times "Please refer to section 6
for the detailed format." Maybe we should see what the WG thinks.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 11 Jan 2016 08:38:22 +1300

> On 11/01/2016 02:38, Carsten Bormann wrote:
...
> stupid initiator field at all.

I had to add three lines of code to the relay function to do this.
So I now propose to remove the 'initiator' field from the messages where
I added it (and add the necessary clarifications about using the source
IP address). That will be a straightforward change to the -02D draft
that I sent yesterday, so co-authors, please let me know what you think
ASAP.

Thanks Carsten, this helped a lot.

    Brian

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 10 Jan 2016 20:57:35 +0100

> just say it in words at this point, without using pseudo-CDDL?

The (not so pseudo) CDDL is fine.
Actually, the CDDL authors added the ".within" annotation to be able to
combine a statement giving a coarse overall structure formally with the
detailed specification.  (Something that would really solve a number of
problems with the way ABNF is used, by the way.)

> for the detailed format." Maybe we should see what the WG thinks.

I don't have a problem with fragments in the text -- in fact, the COSE
group just had extensive deliberations about using those and arrived at
a very good consensus for having the in-line fragments.  I just want to
make sure they do parse, so they can be checked automatically against
the collected specification.  (I'm also not a big fan of restating the
obvious, when that really is likely to be obvious to the reader at this
point.)

>> that I sent yesterday, so co-authors, please let me know what you think

Great!

Grüße, Carsten

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 11 Jan 2016 11:40:11 +1300

Carsten,

Please check the attached revised CDDL.

BTW it still contains the unused Device ID format. I'm inclined to resolve
that open issue by removing it from the draft; we can always add it back later.

Regards
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 12 Jan 2016 08:44:17 +1300

Bing,

> 2. Section 3.3.5.1 Flooding
>> If it receives a multicast Flood message on a given interface, it MUST relay it by re-issuing a Flood message on its other interfaces. The relayed message MAY have a different Session ID.
> [Bing] Is there any concern that different Session IDs for the same flood message?
> My rough idea is that the same Session ID might be beneficial to identify the flooded message. E.g., the interface could easily examine whether the message had been relayed once.

That was what I thought until I started writing the code. It gets very complicated
because of the "birthday paradox" risk of duplicate Session IDs. You have to track
the pair (Session ID, initiator address). That's why I proposed adding an 'initiator'
to several messages (see the discussion with Carsten attached below). The issue is
just the same for flood and discovery.

Relying on the loop count to terminate multicast loops is much simpler.

There are only two ways to create a loop: a bad physical topology, which will create
problems for everybody, not just GRASP, or a faulty GRASP implementation that relays
multicasts back to the same interface, which will be detected during debugging.
So I think the loop count is enough protection.

If we accept that, then using a new Session ID each time a multicast is relayed
to a new link is fine. We do lose the knowledge of which GRASP node originally
generated the Discover or Flood.

What do you think? There would be a few more changes to the text for this.
I have two versions of the Python code already, with or without the 'initiator'
field, and they both seem to work with identical results.

Regards
   Brian

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 12 Jan 2016 08:26:40 +0000

Hi Brian,

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Tuesday, January 12, 2016 3:44 AM
> To: Liubing (Leo)
> Cc: Anima signaling DT
> Subject: Session IDs in relayed messages (and the Initiator field)
> 
> Bing,
> 
> >> If it receives a multicast Flood message on a given interface, it MUST
> relay it by re-issuing a Flood message on its other interfaces. The relayed
> message MAY have a different Session ID.
> > My rough idea is that the same Session ID might be beneficial to identify
> the flooded message. E.g., the interface could easily examine whether the
> message had been relayed once.
> 
> That was what I thought until I started writing the code. It gets very
> complicated because of the "birthday paradox" risk of duplicate Session IDs.
> You have to track the pair (Session ID, initiator address). That's why I
> proposed adding an 'initiator'
> to several messages (see the discussion with Carsten attached below). The
> issue is just the same for flood and discovery.
> 
> There are only two ways to create a loop: a bad physical topology, which will
> create problems for everybody, not just GRASP, or a faulty GRASP
> implementation that relays multicasts back to the same interface, which will
> be detected during debugging.
> If we accept that, then using a new Session ID each time a multicast is
> relayed to a new link is fine. We do lose the knowledge of which GRASP node
> originally generated the Discover or Flood.
> 

[Bing] As you said, it depends on whether we accept loop count is enough. I personally don't have a solid opinion on this. 
I think it's ok to post the 02 as it is, and maybe mark it as a new open question?

Best regards,
Bing

> >>> More odd to me is that the session-id only makes sense in
> >>> conjunction with the initiator, but the latter is not always given.
> >>> I can't quite make rhyme and reason out of when it's there and when
> >>> not.  Maybe that should be explained in the text (beyond what's in
> >>> 3.6), including how the initiator is implied when not present in the
> >>> message (source IP address of UDP packet?).
> >>
> >> discovery messages, because it proved easier to launch a new
> >> discovery session than to propagate the old one.
> >>
> >> You know, I'm going to look at my code again. If I can do the same
> >> trick for flood messages when they are relayed, we just wouldn't need
> >> the stupid initiator field at all.
> >
> > So I now propose to remove the 'initiator' field from the messages
> > where I added it (and add the necessary clarifications about using the
> > source IP address). That will be a straightforward change to the -02D
> > draft that I sent yesterday, so co-authors, please let me know what
> > you think ASAP.
> >