Subject: [Rmt] WG last-call for NORM BB and PI

From: Lorenzo Vicisano <[email-masked]>
Date: Tue, 10 Jun 2003 15:54:45 -0700

Please be advised that RMT Working Group last call is issued
for draft-ietf-rmt-bb-norm-06.txt and draft-ietf-rmt-pi-norm-07.txt,
starting Today.

Please send your comments to this mailing list by Wed June 25th.

	thank you,
	the RMT chairs.
_______________________________________________
Rmt mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rmt

---

From: Vincent Roca <[email-masked]>
Date: Wed, 25 Jun 2003 18:06:05 +0200

Brian and al.,

Please find two comments after a _fast_ reading of the latest NORM PI
draft.

* session_id semantic, p 17:

  The NORM use of this session_id is quite different from that of ALC.
  With NORM, the session_id "uniquely identifies [the sender]
  current instance of parcipitation in the NormSession". So it does
  not identify the session (unlike it is suggested by its name)
  but a sender instance within a session. So at minimum the session_id
  name should be changed for something more explicit (eg. "sender
  instance id").

  With ALC, the session_id "uniquely identifies a session among all
  sessions from a particular sender".
  So the second part of this remark is: how is identified a NORM
  session?
  It seems there's no such mechanism (unless I missed something).
  Two sessions emanating from the same sender are probably
  distinguished by the session multicast address/UDP port... but is
  there something else?
  With ALC, the session (multicast or unicast) address is not used,
  only the {sender IP addr; TSI} tuple. It means that there is a full
  independance between the delivery mechanism (eg. the destination
  address may change while in transit) and the session identifying
  mechanism. OK, the situation is simpler in ALC since only 1-to-many
  sessions are considered, which is not the case of NORM...
  Nevertheless maybe something is missing here, for instance to
  prevent session collisions. I don't how to do that, though! What
  is your feeling?

* definition of the NORM FEC Object Transmission Information (FTI)
  Header Extension, p 21:
  
  This EXT_FTI definition is quite different from that of FLUTE
  (draft-ietf-rmt-flute-00.txt). It does not mean that the NORM version
  is wrong, but it does mean that some harmonization is probably needed
  between the two documents.
  (I don't think there is any good reason to have RM dependant FTI
  formats)
  To be discussed...

Cheers,

  Vincent

---------------------- http://www.inrialpes.fr/planete/people/roca/
  INRIA Rhone-Alpes - projet planete      [email-masked]
  Zirst; 655 av. de l'Europe; Montbonnot  phone (+33) 4.76.61.52.16
  38334 ST ISMIER cedex - France          fax   (+33) 4.76.61.52.52

---

From: Brian Adamson <[email-masked]>
Date: Fri, 27 Jun 2003 22:33:49 -0400

I'm on vacation this week and won't likely get to update the draft 
_before_ the cutoff date, but I will see what I can do. I will be 
back in the office Tuesday.

With regards to the sessionId ... that makes sense to me ... i.e. to 
suggest that senders use a common sessionId for a common session 
instance, and I agree that how this is accomplished may be TBD ... I 
went with the "sender instance" usage because this has been an issue 
in some bulk transfer reliable  multicast applications ... when a 
sender leaves a long-lived session (crashing, terminated, etc) but 
then rejoins relatively quickly ... our implementation(s) of reliable 
multicast have used the objectId space to, if not deterministically, 
randomly to let receivers infer the rejoining sender is a "new" 
instance and they should "resync" to the sender (i.e. previous object 
transpor state they have for the sender may be invalid) ...  I have 
always felt this was a little weak, particularly that within NORM we 
now have a 16-bit objectId space, instead of the 32-bit objectId 
space used within previous protocols.  The "sender instance" usage of 
a sessionId field allows for a more robust solution to this issue ...

However, I understand the usefulness of a sessionId usage which 
allows the reliable multicast session to transcend mere multicast 
address/port number assignment ... this is probably more consistent 
with emerging concepts for transport protocols with more dynamic 
lower layers due to mobility, security, etc.
I think I understand that this is your "session collision" concern?

Perhaps the exact usage of the NORM sessionId field may become more 
well-defined as mechanisms to provide for signalling/agreement to 
sessionId values within a multicast session?  Meanwhile, the NORM 
spec (as an experimental RFC) could discuss these possible different 
usages of the field?  In the end, a receiver's response to a detected 
change in "sessionId" from a given "senderId" is the same ...

With regards to the "flute" FTI definition, I will look into that. 
However, I would like to retain a mechanism within NORM that allows 
for very loosely organized reliable multicast sessions, i.e. where 
receivers can begin interpreting sender transmitted content quickly 
without need for out-of-band information (albeit at the cost of some 
header overhead) ... the FTI extension defined within NORM is 
currently for "fec_id" == 129 ... other header extensions could be 
defined for use with NORM ... to possibly include the "flute" 
definition ... And I will look at the flute draft ... perhaps that 
will remove the need for the fec_id=129 FTI extension defined in the 
current NORM draft ??

-- 
Brian
__________________________________
Brian Adamson
<http://manimac.itd.nrl.navy.mil>
<mailto:[email-masked]>