Subject: RE: [Sip] Message draft changes

From: [email-masked]
Date: Thu, 16 May 2002 17:59:25 +0300

It seems to me that your limitation is on the assumption that Ethernet is the underlying Data Link layer. 

I admit some UDP implementations also limit the UDP datagram size to a smaller value than 64K. But as it says, its an implementation, and that's why the limitation should be an implementation issue depending on the underlying network, the API, etc. and not restricted by the protocol standard.

Regards,
Hisham

> -----Original Message-----
> From: ext Ben Campbell [mailto:[email-masked]]
> Sent: Tuesday, May 14, 2002 5:40 PM
> To: Niemi Aki (NET/Espoo); [email-masked]
> Subject: RE: [Sip] Message draft changes
> 
> 
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Tuesday, May 14, 2002 4:54 AM
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: RE: [Sip] Message draft changes
> >
> >
> > Hi Ben,
> >
> > > I submitted draft-ietf-sip-message-04 last week. This version
> > > contains a few
> > > AD requested changes, primarily in the area of congestion control.
> > > Specifically:
> > >
> > > 1) Added an applicability statement clarifying the difference
> > > between the
> > > pager and session models, and that this draft only defines
> > > the pager model.
> > >
> > > 2) Strengthened the congestion control section:
> > >
> > >    * 1300 byte hard limit for physical payload size for pager
> > > model. This
> > > applies to the actual payload only, not indirect content. 
> Fragmenting
> > > content across multiple requests is prohibited for pager model.
> >
> > I don't agree with this at all. This sort of hard limit really
> > hampers the whole IM application. The session mode and paging
> > mode IM are very different in nature. Session IM is clearly
> > conversational, whereas paging mode IM much more of a
> > "shoot-and-forget" type messaging. Now if the selection between
> > the two is not based on user preference and needs but on payload
> > size, I don't think this serves the IM users very well.
> >
> > Also, 1300 bytes seems awfully little, if I want to send
> > message/cpim with S/MIME protection.
> >
> 
> I understand your concern. The problem is, the IESG is very 
> concerned about
> the potential for congestion caused by MESSAGE. We initially 
> stated that, if
> your payload was over 1300 bytes, you must use a congestion-controlled
> transport. The SIP spec itself says that now, I think. The problem is,
> outside of a dialog, there is no way to ensure that no hop 
> will traverse
> UDP. So to allow larger payloads, we would have to solve that 
> problem first.
> We did not want to make MESSAGE dependent on a solution for 
> that problem.
> 
> There is work underway to define a mechanism for indirect 
> content. I think
> we will have to use that for any sort of large content.
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 16 May 2002 10:08:37 -0500

Actually, I pulled the number out of the bis-09, which says you SHOULD use
congestion control if your content-size is >1300. Clearly, that number
appears to be chosen there for the reasons you mention. I agree with your
statement, but I prefer to keep the number consistent between the message
draft and the SIP spec.

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, May 16, 2002 9:59 AM
> To: [email-masked]; [email-masked]; [email-masked]
> It seems to me that your limitation is on the assumption that
> Ethernet is the underlying Data Link layer.
>
> I admit some UDP implementations also limit the UDP datagram size
> to a smaller value than 64K. But as it says, its an
> implementation, and that's why the limitation should be an
> implementation issue depending on the underlying network, the
> API, etc. and not restricted by the protocol standard.
>
> Regards,
> Hisham
>
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 16 May 2002 15:37:10 -0400

> statement, but I prefer to keep the number consistent between the

Actually, the spec uses 1300 only when the path MTU is not known:

If a request is within 200 bytes of the path MTU, or if it is larger
than 1300 bytes and the path MTU 3572
is unknown, the request MUST be sent using TCP.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 16 May 2002 16:46:09 -0500

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Thursday, May 16, 2002 2:37 PM
> To: Ben Campbell
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Sip] Message draft changes
>
>
>
>
> Ben Campbell wrote:
> >

But, unless the UAC sending a MESSAGE request has only one hop, it is very
unlikely that the UAC can know the MTU for each hop. I can add text handles
the case for when you _do_ know the full path MTU--but I don't think that
situation will occur very often in the pager model.

Thanks!

Ben.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 17 May 2002 11:40:30 -0400

Ben Campbell wrote:
> > > Actually, I pulled the number out of the bis-09, which says you
> SHOULD
> > > use

Careful here! Path and hop mean different things to folks at layer 3 and
at the app layer. The Path MTU refers to the smallest MTU along each
router hop from the IP source to the IP destination. For SIP, that is
just a single "hop" from the UAC to a proxy, say. Each SIP "hop"
(between UAC and proxy, or proxy to proxy) will have a different path
MTU, and could conceivably make a different transport decision based on
that. 

-Jonathan R.

---

From: "Ben Campbell" <[email-masked]>
Date: Fri, 17 May 2002 10:54:56 -0500

> Sent: Friday, May 17, 2002 10:41 AM
> To: Ben Campbell

Ah, thanks for the terminology lession--I mean to say, that it is very
unlikely that the MTU will know the smallest path MTU for every SIP device
end-to-end.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 21 May 2002 03:35:34 -0400

Ben Campbell wrote:

> unlikely that the MTU will know the smallest path MTU for every SIP

Actually, I think you mean to say that it is very unlikely that the UA
will know the path MTU for reaching every sip device. I agree, but its
not the case that it needs to know. In most usages, the UA will talk to
an outbound proxy, and it will know the path MTU to the outbound proxy.
Its determination about whether to use UDP or TCP would then be based on
this specific path MTU.

-Jonathan R.

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 21 May 2002 08:34:37 -0500

> From: Jonathan Rosenberg [mailto:[email-masked]]

[snip]

> Its determination about whether to use UDP or TCP would then be based on

Yes, that is what I mean. Why does only the first hop matter for the UDP/TCP
decision?

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 21 May 2002 12:11:04 -0400

> Yes, that is what I mean. Why does only the first hop matter for the

Because each hop (in the SIP sense) makes an independent decision about
which transport to use, and that decision is a function of the size of
the request and the path MTU to the next hop (in the sip sense).

-Jonathan R.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 21 May 2002 09:23:19 -0700 (PDT)

> the request and the path MTU to the next hop (in the sip sense).

   Well then, SIP imitates the net again. The net has path 
   MTU discovery to get around this problem; why shouldn't
   SIP?

		Mike

---

From: "Dean Willis" <[email-masked]>
Date: Tue, 21 May 2002 15:26:47 -0500

> > not the case that it needs to know. In most usages, the UA 
> will talk 
> > to an outbound proxy, and it will know the path MTU to the outbound 
> > proxy. Its determination about whether to use UDP or TCP 
> would then be 
> > based on this specific path MTU.
> >
> 
> Yes, that is what I mean. Why does only the first hop matter 
> for the UDP/TCP decision?

Because the definition of "proxy" is to "delegate decision-making to
another entity.". The crux of the argument is that once it has left the
UA and gotten safely to the first-hop-proxy, what to do NEXT is now the
proxy's problem. Maybe that next hop proxy implements flow control for
UDP by tunnelling all UDP requests over SSH. Maybe it uses SCTP. But
it's the only one who really KNOWS.

--
Dean

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 21 May 2002 15:54:00 -0500

> From: Dean Willis [mailto:[email-masked]]
> Sent: Tuesday, May 21, 2002 3:27 PM
> To: 'Ben Campbell'; 'Jonathan Rosenberg'

Right, of course--I was confusing myself with the stonger requirement for
MESSAGE, where the fact that some downstream proxy could convert to UDP
causes us to limit request size to 1300. The original question comes from
feedback suggesting this size was unnecesarily arbitrary.

It was also suggested that it should be relative to path MTU to the first
hop. But I am not sure the first hop path MTU is relevant. The real goal is
to keep the size below the path MTU of _all_ hops, _most_ of the time. The
first hop mtu tells you nothing about the rest.

I assume the 1300 default was chosen for SIP in general because of a belief
that, if you have no knowledge of MTU size, that value is a reasonable SWAG.
I don't see how we can do any better for MESSAGE.