Subject: [Sip] Extension to Assure Congestion Safety

From: [email-masked]
Date: Thu, 16 Jan 2003 13:36:28 +0100

Hi

are there news about the Congestion problem ?
I read some weeks ago that work is frozen. 
But your draft expires at the end of January. 
Will be some change in new release? If it will be resubmitted.

About the change with TCP as Transport Protocol default,
someone can tell me some news?

Sal
_______________________________________________
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: Dean Willis <[email-masked]>
Date: 16 Jan 2003 10:26:04 -0600

> someone can tell me some news?

Thanks, Sal. Actually, we haven't talked much about this lately, and we
probably should.

When conversation last stopped, we had just realized that although we
could use this sort of mechanism in the forward direction, it doesn't do
anything about the reverse direction.

So, let's say somebody S/MIME signs a 200 OK, making it perhaps 4KB in
size (That doesn't necessarily happen, but it MIGHT if they include
their cert). Since this is a response, it MUST follow the path laid out
in the Via header field, even if this takes it across non-congestion
safe UDP links.

Is this a problem that we should worry about?

If so, can we address it short of jut deprecating UDP? 

One approach that came up is essentially tagging the Via values so that
we know which are congestion safe. Under this approach, the receiving UA
would be able to recognize that the large response it is generating
could not be returned safely. What should it do then? Could such a
mechanism be made backward compatible?

How much additional triggerwork are we willing to put into the protocol
just to continue accommodating UDP? I know a number of people believe
that a lot of the complexity of SIP stems from its concurrent support
for UDP and TCP, and that we'd be better off just ripping the UDP out
and consequently greatly simplifying the state machines than adding more
complexity to the core protocol.

So, we don't really have a group consensus about where to go with this,
and we need one. 

Ladies, gentleman, and those to whom these terms are irrelevant, the
floor is open for discussion.

--
Dean