Subject: Re: Transport layer interface

From: Brian Rosen <[email-masked]>
Date: Fri, 20 Aug 1999 13:58:31 -0400

Specific editing issues you raised
> 6.6.4.1.5
> Is it necessary to say what a properly configured system is?
This contained in the text as:
"The entities should be able to derive from the past history an
estimate of the packet loss rate due to transmission errors.
In a properly configured system, this loss rate should be kept
very low, typically less than 1%.  "

I find no fault with this.  What suggestions do you have to
improve it.?

> What is a classic algorithm?
This is contained in the text as:
"A classic retransmission algorithm would simply count the
number of successive repetitions, and conclude that the
association is broken after re-transmitting the packet an
excessive number of times (typically between 7 and 11 times.)
In order to account for the possibility of an undetected or
in-progress "failover", we modify the classic algorithm so
that if the Media Gateway receives a valid ServiceChange
message announcing a failover, it will start transmitting
outstanding commands to that new MGC.  Responses to commands
are still transmitted to the source address of the command."

Although we could reference TCP, I find no fault with the text.
Do you have any specific suggestions to improve it.

> We request? does it do it or not?
I will edit this to be declarative

> Does ATM have a DNS?
I have deleted the sections referring to DNS in the transport
sections, since the failover mechanism in MEGACO is somewhat
different from that in MGCP

There is still a reference to DNS as a definition of what
the provisioning of MGCIdentity is.

> The timers are based on IP networks.
They are discussed in the context of IP transport.  If this
was to be used in non-IP transport, the timers may have to
change, but such a change would be transport dependent.
I think it would not be possible to have a transport independent
set of timers in this section.

> Does ATM run IPSEC?
Now that is a good question.

You will forgive me for being sarcastic on this point, as I am
on record in the ATM Forum for blasting the ATM Security spec
as being needlessly different from IPSEC.  I don't believe ITU
has had any ATM security effort.  What it would result in,
I don't know.  Running IPSEC on ATM would be very simple to
define, but it has not been, and is unlikely to be defined so,
at least in the ATM Forum.  Should we define how the protocol
runs on ATM, we will have to decide how to do security.
The interim mechanism is one reasonable possibility.
The ATM Forum Security Spec is another (it is an okay spec,
it's just different for no good reason IMO).

> 6.6.4.1.6
> This property tends to maximise < superflous
Occurs in:
"The MEGACO/Recommendation H.248 does not mandate that the
underlying transport protocol guarantees the sequencing of
transactions sent to an entity.  This property tends to
maximize the timeliness of actions, but it has a few drawbacks."

I find it acceptable.  How would you rewrite it?
"This can maximize..."?

> Can use following rules < is that a should, shall, may ?
I'll change to "may"

> 6.6.4.1.7
> Media Gateway Controllers are typically dimensioned .........
> <Is this telling me what an implementation is? Do we really need this
> section given the different applications an MC or MG will face>
This occurs in:
"The following reasoning can be used to determine the value of
this delay on residential gateways.

Media Gateway Controllers are typically dimensioned to handle
the peak hour traffic load, during which, in average, 10% of
the lines will be busy, placing calls whose average duration
is typically 3 minutes.  The processing of a call typically
involves 5 to 6 Media Gateway Controller transactions between
each Media Gateway and the Media Gateway Controller.  ....."

It is qualified by saying residential gateway, it's an estimate
illustrating a possible way to determine MWD, but it is not
the only way.  I'm not in favor of eliminating it, because it
provides good guidance for a common situation.  If you have
suggestions for improving the language, I'm ammenable to editing
it.

---

From: Christian Groves <[email-masked]>
Date: Mon, 23 Aug 1999 17:53:04 +1000

Interesting note about the ATMF......4 little words opened a can of
worms.

My suggestions were pretty much the italics text in the draft with
suggested headings. As I seem to be the only one concerned with the
format and text in the ALF and TCP IP transport section, i'll leave it
be.

Cheers, Christian