Re: Further comments on the proposed RFC

[Gorry Fairhurst <gorry@erg.abdn.ac.uk>]

"Walsh Rod (NRC/Tampere)" wrote:
> 
> Hi Gorry et al.
> 
> Thanks for the super fast response. Just a few answers with text cut...
> 
> > GF: Yes, do we need a different one for the return path too?
> 
> I do not feel the need to include them, but am happy to see them from
> anyone keen on DVB radio return channels. (Just that the two paths
> should be illustrated seperately to keep understanding clear).
> 

GF: OK. This is then possible future text as and when needed.

> > GF: I'll just call them sections if it is clearer.
> > So.... in the rev I am writing, I now have:
> > |         | | | | |   | AAL5 | DSMCC  |  |  |
> > |         +-+-+-+-+---+------+--------+--+--+
> > |         | PES  |   ATM     |  Sections    |
> > +---------+-------+----------+--------------+
> 
> "Private Sections" is the correct term. "DSM-CC Sections" may also be
> called "sections" - "Priv.Sect." fits the space:)
> 

GF: Excellent, from looking at the MPEG 13818, I came to this too, and
I'm impressed it fits perfectly :-)

> > GF: I agree, I suggest at the moment to talk only about "SI"
> > in the most general sense.
> ...
> > Is that OK, or would you like to suggest alternate?
> 
> That's great. Alternatives aren't needed in the current document scope.
> 
> > GF: In the version I am working on (I'll send this out in the next
> > week, so everyone can look at it), a "TS Multiplex" is a
> > series of consecutive transport packets all sent over the same
> physical
> > link. This is a key term - we need to get the right name and meaning.
> ...
> > Would that be OK?
> > Would "TS logical channel" be better, "TS Channel" is shorter?
> ...
> > GF: I'll write new text and see if we can converge.
> 
> "TS logical channel" is better, but even so we'll have some terminology
> issues. "Component" seems to fit best, but I'm open to better arguments.
> Also check the IP-CC requirements pdf previously posted to the reflector
> - there are some definitions originating from DVB which should be
> useful.

GF: Suggest we go with "TS logical channel" - The word "component"
seems a bit alien to IETF, and more video-like. If people decide
afterwards they hate it, we can change again.

> 
> > GF: Nice idea!!! I'm not sure this IETF work, maybe it is?
> > - It would be useful to have an ID on this, so we could
> > evaluate how easy it would be to define benchmarking
> > terms and appropriate tests.
> 
> "RFC2357 IETF Criteria for Evaluating Reliable Multicast Transport and
> Application Protocols" or "RFC2477 Criteria for Evaluating Roaming
> Protocols" may be good a example of how this could be done in the IETF
> context.

GF: There was a also the IP benchmarking work for Ethernet switches etc...
I'll add some place-holder text in a new section:

"7. Evaluation of transmission of IP datagrams over DVB networks

A set of methodologies may be defined to assist in the evaluation 
of the protocols defined by this framework. These could define 
terminology, evaluation criteria (utilisation, throughput, 
loss rate, undetected error rate, etc), and may specify tests 
to indicate the impact of such parameters as IP Datagram size, 
IP version, multicast/unicast, and rate of transmission.  A set 
of test cases could also be defined to allow performance to be 
quantitatively measured and compared.

Is this sort of in the right direction?

If it seems useful we can add to it later, and then add it to 
the charter?

> 
> > GF: Do we need bi-directional (duplex) communication between end hosts
> to
> > use IPSEC - I thought providing you could distribute keys, one-way
> would
> > be fine --- can someone check this?
> 
> It is not essential to use a bi-directional link for IPsec key delivery.
> But if we include IPsec issues we must not exclude a return channel
> (since it will "probably" offer higher security).
> 

GF: OK, I'll NOT put it in now.

> Yours,
> Rod Walsh.