Subject: Re: [midcom] Comments on requirements draft v2

From: Mark Duffy <[email-masked]>
Date: Thu, 02 Aug 2001 19:01:18 -0400

At 04:40 PM 8/2/01 +0100, Cedric Aoun wrote: 

<excerpt>4.4.    Distribution of MIDCOM elements 

"The Middlebox therefore needs to support multiple simultaneous 

   MIDCOM Agents" 

We should also state: 

Similarly a Midcom agent should support multiple simultaneous Middle
Boxes.  

</excerpt><<<<<<<<

MD:

I believe it is out of place to state these kind of requirements here on
agent and middlebox -- those are for the market to impose (or not). 
Rather, this protocol requirement should state that the midcom protocol
must provide the support necessary for multiple agents per middlebox and
multiple middleboxes per agent.

<excerpt>

5. page 6 

Pinhole opening are not the only things the Midcom protocol should allow
the  

Midcom agent to request the Middle box to do. 

Address and ports binds need to be added, a statement should say that
other  

middle box functions will be handled as well but not in the initial
version of the protocol. 

</excerpt><<<<<<<<

MD:

It was my understanding that address/port (i.e. NAT/NAPT) binds would be
allocated and assigned by the middlebox, and that the agent could use the
midcom protocol to *learn* these bindings.  Certainly, that makes support
of multiple agents per NAT middlebox much simpler.   The timeline
diagrams in the framework doc do show it working this way, at least as I
interpret them.

I did raise a question recently about whether the agent needs to be able
to influence the address/port bindings in such a way as to ensure e.g.
that related flows were assigned bindings with the same IP address.  I do
not understand the relevant applications well enough to know if this is a
requirement.

<excerpt>

</excerpt>

_______________________________________________
midcom mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/midcom

---

From: Melinda Shore <[email-masked]>
Date: Thu, 02 Aug 2001 19:16:04 -0400

At 07:01 PM 8/2/01 -0400, Mark Duffy wrote:
>I did raise a question recently about whether the agent needs to be able to influence the address/port bindings in such a way as to ensure e.g. that related flows were assigned bindings with the same IP address.  I do not understand the relevant applications well enough to know if this is a requirement. 

This should be fairly simple to put in the protocol.  A NAT mapping
request can potentially include a requested NATted-to address and/or
port, along with a flag that could say "if it's not available don't
install the mapping" or "if it's not available give me something else
and tell me what it is."

Melinda

---

From: "Bob Penfield" <[email-masked]>
Date: Fri, 3 Aug 2001 09:11:50 -0400

----- Original Message -----
From: "Mark Duffy" <[email-masked]>
To: "Cedric Aoun" <[email-masked]>; "Richard Swale (E-mail)"
<[email-masked]>
Cc: "Midcom IETF (E-mail)" <[email-masked]>
Sent: Thursday, August 02, 2001 7:01 PM
Subject: Re: [midcom] Comments on requirements draft v2

>   4.4. Distribution of MIDCOM elements
Boxes.
> <<<<
agent and middlebox -- those are for the market to impose (or not). Rather,
this protocol requirement should state that the midcom protocol must provide
the support necessary for multiple agents per middlebox and multiple
middleboxes per agent.

<BP>
I like Mark's language here. The original text reads like it is imposing
requirements on the middlebox itself which we should not do.
</BP>

the
other
version of the protocol.
> <<<<
allocated and assigned by the middlebox, and that the agent could use the
midcom protocol to *learn* these bindings. Certainly, that makes support of
multiple agents per NAT middlebox much simpler. The timeline diagrams in the
framework doc do show it working this way, at least as I interpret them.
> I did raise a question recently about whether the agent needs to be able
to influence the address/port bindings in such a way as to ensure e.g. that
related flows were assigned bindings with the same IP address. I do not
understand the relevant applications well enough to know if this is a
requirement.
<BP>
There are at least two cases I can think of where the agent wants to tell
the middlebox what the binding is: 1) when establishing the NAT to allow SIP
signalling through the middlebox (It will likely want to make the port be
5060); and 2) for when there are redundant peering points and the agent
wants to same binding in both NAT middleboxes. It might "learn" the binding
from one middlebox and "tell" the other middlebox that binding.
</BP>

---

From: Jiri Kuthan <[email-masked]>
Date: Thu, 09 Aug 2001 15:09:05 +0200

>I did raise a question recently about whether the agent needs to be able to influence the address/port bindings in such a way as to ensure e.g. that related flows were assigned bindings with the sam…

draft-kuthan-fcp-02.txt (to-be-expired-now):

"It is needed, for example, by RTP [9], which recommends allocation of even port numbers for itself, subsequent port number for RTCP and contiguous block of port numbers for layered encoding applications."

-Jiri

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

---

From: Jiri Kuthan <[email-masked]>
Date: Thu, 09 Aug 2001 15:18:25 +0200

I think this discussion appeared on the mailing list looong time
ago and most folks agreed that asking for NAT translation goes
better than setting it.

If we went for "setting", agents (e.g., SIP proxies) would have
to maintain the address pool. Not only does it counter midcom's
decomposition prinicple, but it also introduces lot of tricky
issues. Particularly, things will become more complex with
multiple agents.

-Jiri

---

From: Mark Duffy <[email-masked]>
Date: Sat, 11 Aug 2001 14:53:07 -0400

Jiri, Suresh,

There has been a lot of discussion about the some of the terms and I
believe someone took an action in London to improve the definitions.

I will leave it to others to select the terms themselves but I would assert
that we should have a separate term for each of the following concepts (at
least):

  <#1>  A single instance of an application-to-application flow of packets
which is identified by source address, source port, destination address,
destination port and protocol id.  (That is the definition for "Microflow"
in RFC 2465 diffserv).

  <#2>  An n-tuple classifier rule within the middlebox (for our purposes,
the rule is placed there using the midcom protocol) that specifies one or
more instances of <#1>.

  <#3>  An action, associated with a specific <#2>, that the middlebox will
apply to packets of any <#1> matching that <#2>.

  <#4>  The set of <#1>'s associated with a single application session.
E.g. all the microflows associated with a given SIP call.

  <#5>  The set of <#2>'s within the middlebox that correspond to a <#4>.
E.g. all the classifier rules that relate to microflows associated with a
given SIP call.

In particular, the above will give us a rich enough set of terms to
distinguish between sets of packets flowing through the network (<#1>,
<#4>, and artifacts in the middlebox the relate to those sets of packets
(<#2>, <#3>, <#5>).

-- Mark